ingress (legacy)

1ctl ingress manages the Kubernetes Ingress resources that bridge your domain name and your running application. This is the legacy/manual routing surface; current default deploys use Gateway API HTTPRoutes. An Ingress is an HTTP routing rule: it tells the nginx ingress controller which Service to forward requests to when traffic arrives for a given hostname.

public request → nginx LoadBalancer → Ingress rule (hostname match) → Service → pods

In legacy/manual ingress mode, 1ctl deploy --domain <domain> creates an Ingress automatically. Use these commands when you need to manage routing rules directly — for example, to add a second hostname, swap the backing Service, or attach a custom domain after the initial deploy.

Commands

`1ctl ingress list`

1ctl ingress list

Lists all Ingress rules in the current organisation. The output shows the name, the deployment and Service it routes to, the hostname, TLS status, and namespace.

Flags

Flag	Short	Default	Description
`--output`	`-o`	`table`	Output format: `table` or `json`.

Examples

# List all ingresses in the active org
1ctl ingress list

# Machine-readable output
1ctl ingress list -o json

`1ctl ingress upsert`

1ctl ingress upsert \
  --deployment-id <id> \
  --service-id <id> \
  --app-label <label> \
  --namespace <ns> \
  --domain <domain> \
  [--port <port>] \
  [--custom-dns]

Creates a new Kubernetes Ingress rule for a domain, or updates it if one already exists for the same hostname in that namespace. This is idempotent.

Flags

Flag	Default	Description
`--deployment-id <id>`	required	ID of the deployment this Ingress routes traffic to.
`--service-id <id>`	required	ID of the Service that receives forwarded requests.
`--app-label <label>`	required	Kubernetes app label of the deployment. Used to name the cert-manager Issuer reference.
`--namespace <ns>`	required	Kubernetes namespace to create the Ingress in.
`--domain <domain>`	required	Public hostname this Ingress handles (e.g. `api.myapp.com`).
`--port <port>`	`80`	Target port on the Service.
`--custom-dns`	false	Set when you are managing the DNS A record yourself (see DNS modes below).

Under the hood:

POST /v1/cli/ingresses/upsert

A Kubernetes Ingress resource is created (or patched) with the following annotations:

kubernetes.io/ingress.class: nginx
cert-manager.io/issuer: {app-label}-letsencrypt-nginx
acme.cert-manager.io/http01-edit-in-place: true

The cert-manager.io/issuer annotation tells cert-manager to obtain a TLS certificate for the domain. cert-manager performs an ACME HTTP-01 challenge by temporarily adding a path to the Ingress itself, then stores the resulting certificate as a Kubernetes Secret.
The Ingress record is written to the ingresses table.

Examples

# Create an ingress for api.myapp.com
1ctl ingress upsert \
  --deployment-id dep_01abc \
  --service-id svc_04xyz \
  --app-label my-api \
  --namespace production \
  --domain api.myapp.com

# Target a non-default service port
1ctl ingress upsert \
  --deployment-id dep_01abc \
  --service-id svc_04xyz \
  --app-label my-api \
  --namespace production \
  --domain api.myapp.com \
  --port 3000

# Bring your own DNS
1ctl ingress upsert \
  --deployment-id dep_01abc \
  --service-id svc_04xyz \
  --app-label my-api \
  --namespace production \
  --domain api.myapp.com \
  --custom-dns

`1ctl ingress delete`

1ctl ingress delete --ingress-id <id> [-y]

Deletes an Ingress rule. Traffic to the associated domain stops routing immediately. The TLS certificate Secret is not deleted — cert-manager retains it. The domain itself and its DNS record are also unaffected.

Flags

Flag	Short	Default	Description
`--ingress-id <id>`		required	ID of the Ingress to delete. Use `1ctl ingress list` to look up IDs.
`--yes`	`-y`	false	Skip the confirmation prompt.

Examples

# Delete with confirmation
1ctl ingress delete --ingress-id ing_07def

# Non-interactive
1ctl ingress delete --ingress-id ing_07def -y

DNS modes

When you create an Ingress, Satusky needs the domain’s DNS A record to point to the cluster’s nginx LoadBalancer IP. There are two ways to handle this:

Satusky-managed DNS (default)

Satusky uses Cloudflare and the external-dns operator. When you create an Ingress without --custom-dns, external-dns automatically creates or updates a Cloudflare DNS A record pointing to the LoadBalancer IP. No action is required on your part.

Custom DNS (--custom-dns)

Pass --custom-dns when you control the DNS for the domain outside Satusky. You are responsible for creating the A record. To find the LoadBalancer IP to point to:

# Get the cluster LoadBalancer IP
1ctl cluster list

Then add an A record at your DNS provider:

api.myapp.com  →  A  →  <LoadBalancer IP>

TLS certificate issuance via ACME HTTP-01 proceeds the same way in both modes — cert-manager just needs the domain to resolve to the cluster.