Tenant Operations #
For whoever is building something on Deevnet — you know Terraform, you may not know Deevnet, and you want a device or a service running on the platform without learning how the platform is built.
A picture to keep in mind: the mobile kit is set up at a meetup of a local microcontroller and edge-compute group ( CARPE, for example), and you want a Pico W or an ESP32 on your bench to send messages to a backend. This section walks from “I have nothing” to that.
What a tenant is #
A tenant is your own isolated slice of the platform, declared in your own Terraform and created through the Deevnet API. It gets its own network, its own DNS zone, its own Wi-Fi key for devices, its own MQTT topic space and its own log partitions. Other tenants cannot reach any of it, and you cannot reach theirs.
You hold one credential: a Deevnet API token. You never touch the hypervisor, the router, the
switch or anyone’s vault — you declare resources with the deevnet/deevnet provider and the
substrate builds them. Everything you get is rebuilt from your repository and your Terraform state,
so the repository is the tenant.
The design behind this is in Tenant architecture; you do not need to read it to use this guide.
The service catalog #
| Service | What you get | Status |
|---|---|---|
| Network & workloads | A private /24, an anycast gateway, outbound internet, and Fedora VMs | Available |
| DNS | <tenant>.mobile.deevnet.net and its reverse zone, written by you | Available |
| Wi-Fi keys | A per-tenant key on the IoT SSID, landing your devices on the IoT network | Available |
| Devices & MQTT | A device registry, TLS MQTT accounts confined to your own topics, and a fixed address for a device that needs one | Available |
| Logs | Your own log partitions: workload logs, and device logs arriving over MQTT | Available |
| Dashboards | A Grafana organization of your own with your logs wired in; dashboards as code | Available |
| State store | An S3 backend for your Terraform state | Available |
| Metrics, identity, object storage | Designed, not yet built | Coming soon |
Reading path #
- Getting started — Before you start → Admission → First apply
- Walkthrough: a Pico W or ESP32 talking to a backend — the whole thing end to end, in one Terraform file and two short firmware sketches
- Deploy your app to a workload — your code from your computer onto your own VM, as a container over SSH
- Services — one page per service, when you need the details
- Recovery — when your tenant, or the site under it, loses something
- Connect device to Wi-Fi — your tenant’s Wi-Fi key onto a Pico W, an ESP32 or a borrowed kit
- Convert a tenant to a Pi image — your app and the services it uses move onto a Pi of your own, and your devices keep talking to it with the same topics and tokens, with no Deevnet behind it
- Pi Lab — the site’s own bank of Pis, when your project needs a Pi at the site rather than a VM. Not a Pi of your own
- Troubleshooting — when something doesn’t work
The operator’s side of all this — admitting your name — is Tenant Admission.