Networking

Runix handles networking automatically. Every web service gets a public URL, and all services within a deployment can communicate privately through internal networking.

Default Subdomains#

Every web service is assigned a unique subdomain on `runixcloud.dev`:

https://<service-name>-<hash>.runixcloud.dev

For example, a service named `api` might get `api-a1b2c3.runixcloud.dev`. The hash is a short unique identifier to prevent collisions.

$ runix status api
NAME   TYPE          STATUS    INSTANCE   URL
api    web-service   running   starter    api-a1b2c3.runixcloud.dev

Internal Networking#

All services in the same deployment share a Docker network. They can reach each other using the service name as the hostname.

services:
  - name: api
    type: web-service
    repo: https://github.com/alice/api
    env:
      AUTH_URL: "http://auth:4000"
      CACHE_URL: "redis://cache:6379"

  - name: auth
    type: private-service
    repo: https://github.com/alice/auth
    env:
      PORT: "4000"

  - name: cache
    type: redis

In this example, the `api` service can reach `auth` at `http://auth:4000` and `cache` at `redis://cache:6379`. These internal connections never leave the Docker network.

Connection Strings#

Database services (PostgreSQL, Redis, Kafka) expose a `connection_string` that can be referenced from other services using variable interpolation:

env:
  DATABASE_URL: "${db.connection_string}"
  REDIS_URL: "${cache.connection_string}"
  KAFKA_BROKER: "${events.connection_string}"

The connection strings include the internal hostname, port, and credentials. Runix generates them automatically when provisioning the database.

Port Assignments#

Services listen on the port defined by the `PORT` environment variable. For web services, Runix routes external traffic to this port through the reverse proxy.

TLS / HTTPS#

All public traffic is encrypted with TLS. Caddy reverse proxy handles certificate provisioning and renewal automatically for both default subdomains and custom domains. Internal service-to-service traffic is unencrypted (plain HTTP/TCP) since it stays within the Docker network.