Networking

App hostnames and TLS

When you create an app, Mikrom assigns it a hostname derived from the app name:

<app-name-slug>.<apps-domain>

The name is slugified (lowercased, non-alphanumeric runs become -). The hostname is unique across the platform.

On the first successful deployment, mikrom-api triggers ACME certification for that hostname and mikrom-router serves it over HTTPS. Certificates renew automatically. Bringing your own domain is not self-service yet — see Domains and TLS.

Ingress

mikrom-router (built on Pingora) is the only entry point for application traffic:

Terminates TLS and routes by hostname to the app’s active deployment.
Runs health checks and shifts traffic on activate/rollback.
Holds the persisted routing table and ACME state (in its own PostgreSQL).
Handles scale-from-zero: a request to a sleeping app wakes it.

The control-plane API is not in this path.

The platform network

IPv6-first. Workers and microVMs are addressed on an IPv6 mesh.
WireGuard mesh. mikrom-network manages host identity, peer state, and route synchronization between workers.
Internal DNS. mikrom-dns resolves platform, worker, and tenant names for service-to-service traffic.
NAT64 / DNS64. For workloads that need to reach IPv4-only destinations, mikrom-dns synthesizes DNS64 answers and mikrom-agent runs a host NAT64 translator so guest IPv4 egress works over the IPv6 network.
eBPF data plane. mikrom-agent loads an eBPF program (mikrom-agent-ebpf) for host-side network handling and metrics.

Per-app firewall rules

Each app has a set of security-group rules managed through the API:

GET    /v1/apps/{app-name}/security-groups
POST   /v1/apps/{app-name}/security-groups
DELETE /v1/apps/{app-name}/security-groups/{rule-id}

Use these to constrain ingress/egress for an app beyond the default policy. See the API Reference for the rule schema.

Service mesh visibility

GET /v1/networking/mesh (and its /stream variant) exposes the current mesh state — useful for operators diagnosing peer or route problems.