Services on Deevnet IoTaaS

Network & Workloads

Mon, 01 Jan 0001 00:00:00 +0000

Network & Workloads Available #

What you get #

Creating the tenant gives you a network before you declare anything else:


A `/24` of your own	from `10.20.128.0/18` — `deevnet_tenant.this.subnet`
An anycast gateway	`.1` of it — `deevnet_tenant.this.gateway`
Outbound internet	SNAT on the way out; the outside world sees the platform, not your subnet
Isolation	your network is its own routing domain (a VRF). Other tenants cannot reach it, and it cannot reach them

A workload is a Fedora VM on that network, addressed by cloud-init from your subnet (.10 upward; .2–.9 are reserved). There is no DHCP on tenant networks — addresses are assigned, not leased, so a rebuilt workload comes back at the same address.

DNS

Mon, 01 Jan 0001 00:00:00 +0000

DNS Available #

What you get #

Your own zone, <name>.mobile.deevnet.net, and its reverse zone, served authoritatively by the platform and delegated from the site resolver — so anything that resolves through the site (workloads, trusted seats) finds your names. You write the records; the platform never writes one on your behalf ( ADR-0004).

Declare a record #

resource "deevnet_dns_record" "api" {
 tenant = deevnet_tenant.this.name
 name = "api" # -> api.<name>.mobile.deevnet.net
 address = deevnet_workload.backend.address # must be inside your own subnet
}

The matching PTR record is created for you. Workloads already get a name of their own; a record is for the service name you want other things to use, so the workload behind it can change.

Wi-Fi Keys

Mon, 01 Jan 0001 00:00:00 +0000

Wi-Fi Keys Available #

What you get #

A Wi-Fi key of your own on the site’s IoT SSID. Devices that join with it land on the IoT network (VLAN 30, 10.20.30.0/24 at the mobile site), where they can reach the MQTT broker and the internet — and nothing else: not your workloads, not the management network, not other tenants' services.

The SSID is shared; the key is yours. The access point uses per-key passphrases (PPSK), so your key identifies your devices as yours, and revoking it disconnects only yours.

Devices & MQTT

Mon, 01 Jan 0001 00:00:00 +0000

Devices & MQTT Available #

What you get #

A device registry — your own inventory of what you have flashed
MQTT accounts on the platform broker, each confined to your own topic space

The broker is where devices and workloads meet. Neither connects to the other; both dial out to it.


Broker	`mqtt.mobile.deevnet.net`, port 8883, TLS only — nothing listens on 1883
Certificate	issued by the site CA — trust `site-ca.pem`
Who can reach it	the IoT network (your devices) and tenant networks (your workloads)
Your topic space	everything under `<tenant>/` — and nothing else

Declare a device and its account #

resource "deevnet_iot_device" "pico" {
 tenant = deevnet_tenant.this.name
 name = "pico-1"
 trust_class = "iot"
 # mac = "28:cd:c1:..." # optional; recorded, never used as authorization
}

resource "deevnet_iot_broker_account" "pico" {
 tenant = deevnet_tenant.this.name
 name = "pico-1"
 device = deevnet_iot_device.pico.name

 # Relative to your tenant: the API adds the "<tenant>/" prefix itself.
 publish = ["sensors/pico-1/telemetry", "log/pico-1"]
 subscribe = ["sensors/pico-1/command"]
}

output "pico_mqtt" {
 value = {
 username = deevnet_iot_broker_account.pico.username # "<tenant>-pico-1"
 password = deevnet_iot_broker_account.pico.password
 publish = deevnet_iot_broker_account.pico.granted_publish
 }
 sensitive = true
}

A workload’s account is the same resource without device:

Logs

Mon, 01 Jan 0001 00:00:00 +0000

Logs Available #

What you get #

Three log partitions of your own in the platform log store, and two tokens ( ADR-0027):

Partition	What lands there	How it gets there
`(index, 0)`	your workloads’ logs	you ship them, with your ingest token
`(index, 1)`	what the platform says about your tenant	the platform
`(index, 2)`	your devices’ logs	devices publish to MQTT; a bridge carries them

index is your tenant’s index (deevnet_tenant.this.index). The tokens and endpoint are attributes of your tenant: log_endpoint, log_ingest_token, log_read_token, log_select_header.

Dashboards

Mon, 01 Jan 0001 00:00:00 +0000

Dashboards Available #

What you get #

A Grafana organization of your own, with your logs already wired in ( ADR-0024). Your login is an Editor there, and a member of no other organization. You build folders and dashboards. The platform owns the data sources.

Data source UID	Reads
`deevnet-logs-workloads`	`(index, 0)`, your workloads’ logs
`deevnet-logs-platform`	`(index, 1)`, what the platform says about your tenant
`deevnet-logs-devices`	`(index, 2)`, your devices’ logs from MQTT	the default

Each one reads with your tenant’s own log read token, so it sees exactly what your token sees and nothing more ( Logs).

State Store

Mon, 01 Jan 0001 00:00:00 +0000

State Store Available #

What you get #

An S3-compatible place for your Terraform state, with a key prefix only your credentials can reach ( ADR-0007). It is offered, not required — keeping state yourself is a valid choice, as long as you keep it carefully: it holds every credential your tenant was issued.

Move your state into it #

The credentials are attributes of your tenant, so this happens after the first apply:

Coming Soon

Mon, 01 Jan 0001 00:00:00 +0000

Coming Soon #

Services that are designed — each has an architecture decision record — but not built. Nothing here can be declared today. The shape described is the proposal’s, and may change before it ships.

Secrets #

Coming soon

Today: anything secret your application needs lives in your Terraform state or your own tooling. Planned: a namespace of your own in the platform secrets store, holding a runtime copy of secrets your repository owns, written through the API, and read by your workloads with their own identity. ADR-0021