remote

A reference to a service running outside the orchestrator's control — managed cloud (AWS RDS, Upstash Redis, Qdrant Cloud), a team-shared dev environment, or anything else that's already up and just needs to be wired into the dependency graph.

Manifest knobs

[services.prod-pg]
type = "remote"
url = "postgresql://user@db.staging.internal:5432/app"
kind = "postgres"                    # optional; informs the inspector
healthcheck = { kind = "tcp", host = "db.staging.internal", port = 5432 }

remote is the only service type where the orchestrator never spawns a process. The lifecycle is just healthcheck + dependency gating.

Lifecycle

• Install / init / start: no-op.
• Healthcheck: whatever the manifest declares. TCP to a host is the typical shape.
• Stop: no-op (we don't own the remote).

Inspection drawer

The inspector pulls whatever it can given the kind:

• postgres → connection-string + table list (if reachable from the local box).
• redis → INFO keyspace + sample keys.
• Other kinds → just the URL + healthcheck status.

$<NAME>_PORT injection

Dependents see $<NAME>_HOST + $<NAME>_PORT parsed out of the declared url, same shape as a local service. So pointing an app at staging-Postgres from a local dev session is a one-line manifest change.

Security note

The orchestrator does not redact url in logs by default. If your URL contains a password, model it via a @keychain:<name> reference:

[services.prod-pg]
type = "remote"
url = "postgresql://user:@keychain:prod_pg_password@db.staging.internal:5432/app"

The Keychain backend resolves the reference at start; the literal manifest never carries the password and the support-bundle generator redacts it.

When to use this

• You're integrating with a production / staging service you can't run locally.
• You want the dependency graph to show the dependency even though the orchestrator isn't responsible for the dependency's uptime.
• A teammate's machine already runs a service the project needs and you don't want a second copy.