Services

A service is an HTTP ingress object — think of it as a load balancer entry that the edge proxy uses for routing. Each service is bound to a host (domain) and defines how incoming requests reach your running instances.

Hosts

A host is a domain (or *.unisrv.dev subdomain) linked to a service. Claiming a host reserves it for your account and lets you provision a TLS certificate via Let's Encrypt.

Managed subdomains (*.unisrv.dev) are instantly available with no DNS setup. Just claim a name and you're live.

Custom domains require DNS pointed at the Unisrv edge before a certificate can be provisioned:

CNAME flattening (supported by Cloudflare and others) is recommended for apex domains.

Targets

A target is an instance + port pair registered on a service (e.g. an instance listening on port 80). When a request hits the service, the edge proxy forwards it to one of the registered targets.

Services can have multiple targets for redundancy and load distribution. During a rollout, both old and new targets coexist briefly, giving you zero-downtime deployments.

Target groups

Targets are organized into groups. Every target belongs to a group (default: default). Groups let you segment instances within a single service — for example, separating a frontend group from an API group, each backed by different container images.

The unisrv rollout command operates on a single target group at a time, replacing all instances in that group while leaving other groups untouched.

Locations

Locations provide path-based routing within a service. A location maps a URL path prefix to a target group or an external URL.

For example, a service on app.example.com could route:

• / to a frontend target group
• /api to an api target group
• /docs to an external documentation site

Each location can also specify a custom 404 override path for handling not-found responses.

Without any explicit locations, all paths route to the default target group.

Rules

Services enforce rules on incoming traffic:

• HTTPS enforcement — by default, services only accept HTTPS connections. HTTP requests are rejected. This can be relaxed to allow plain HTTP if needed (e.g. for health checks behind a separate proxy).

How traffic flows

1. A request arrives at the Unisrv edge proxy for a claimed host
2. The proxy resolves the host to a service
3. The service matches the request path against its locations
4. The matching location identifies the target group
5. The proxy selects a target from that group and forwards the request to the instance

All of this happens over private mTLS tunnels between the edge and the node running the instance — traffic is encrypted end to end.