satusky.toml

satusky.toml is the project manifest read by 1ctl deploy. Command-line flags override values from the selected file.

The CLI discovers configuration in this order:

1. The path or name supplied with --config
2. satusky.toml in the current directory

Minimal file

[app]
name = "api"
port = 8080

When omitted, the current CLI defaults are a 250m CPU request, a 1 CPU limit, and 256Mi memory.

[checks]

[checks]
  health_path = "/health"

health_path is an explicit public HTTP health endpoint. It has the same meaning as 1ctl deploy --health-path /health; the CLI flag takes precedence. When you use 1ctl deploy --wait, a successful response from this path can verify application readiness only after the public route is available and the HTTP request succeeds. Use a path that returns a successful response without authentication when the application is healthy.

This is not a replacement for the workload readiness signal: replica counts or generic public reachability alone do not verify that the application is ready. Without an explicit health path, --wait relies on the backend’s live application-readiness condition.

To configure that Kubernetes readiness basis directly, add one probe handler:

[checks.readiness]
  initial_delay_seconds = 2
  timeout_seconds = 2
  period_seconds = 5

[checks.readiness.http_get]
  path = "/health"
  port = 8080

[checks.readiness] accepts exactly one of http_get, tcp_socket, or exec. A passing configured readiness probe can produce the readiness_probe application basis. A deployment with no configured probe is reported as unconfigured, rather than being inferred ready from its replica count.

[app]

Field	Type	Purpose
name	string	Stable application name used for updates
port	integer	Port on which the container listens
domain	string	Optional custom domain
cpu_request	string	Guaranteed CPU reservation, such as 250m
cpu_limit	string	Maximum CPU burst, such as 1
memory	string	Memory request and limit, such as 256Mi
replicas	integer	Manual replica count when HPA is disabled
zone	string	Optional deployment zone

The legacy cpu field maps to the CPU limit. Prefer cpu_request and cpu_limit in new files.

[build]

[build]
dockerfile = "Dockerfile"

dockerfile belongs in [build], not [app]. Omit the section when the default Dockerfile is at the project root.

[checks]

[checks]
health_path = "/health"

The path is used for the post-deploy HTTP smoke check. The application must listen on app.port and return a successful response on this path.

[deploy]

[deploy]
strategy = "rolling"
rolling_max_surge = "25%"
rolling_max_unavailable = "0"

strategy supports rolling and recreate. Rolling values accept an integer or percentage.

[volume]

[volume]
size = "20Gi"
mount = "/data"
storage_class = "ceph-block"

Use a volume only for data that must survive pod replacement. Stateful applications must also support safe single- or multi-replica operation themselves.

[hpa]

[hpa]
enabled = true
min_replicas = 2
max_replicas = 10
cpu_target = 70
memory_target = 80

Set memory_target = 0 to omit memory scaling. Do not use 1ctl app scale while HPA owns the replica count.

[vpa]

[vpa]
enabled = true
mode = "Off"
min_cpu = "100m"
max_cpu = "2"
min_memory = "128Mi"
max_memory = "2Gi"

Supported modes are Off, Initial, and Auto.

[pdb]

[pdb]
enabled = true
type = "fixed"
min_available = 2

PDB type supports auto, fixed, and percent. Use min_available_percent for a percentage policy.

[multicluster]

[multicluster]
enabled = true
mode = "active-passive"
backup_enabled = true
backup_schedule = "daily"
backup_retention = "168h"
backup_priority_cluster = 1

Modes are active-active and active-passive. Backup schedules are hourly, daily, or weekly.

Multiple config files

1ctl deploy --config staging
1ctl deploy --config ./deploy/satusky.toml

--config staging resolves to satusky.staging.toml next to the discovered base config. An explicit path selects that file directly.