init

1ctl init creates a satusky.toml file in the current directory. This file is the source of truth for how 1ctl builds and deploys your application. Every subsequent 1ctl deploy reads it to know what to send to the API.

You only run init once per project (or when starting a new environment config). After that, edit satusky.toml directly.

Command

1ctl init [--config <name>]

Flags

Flag	Description
--config <name>	Write to satusky.<name>.toml instead of satusky.toml. Used for named environment configs.

With no flags, 1ctl init writes satusky.toml and prompts you for each field interactively:

$ 1ctl init
App name:     my-api
Port:         8080
CPU:          0.5
Memory:       256Mi
Dockerfile:   Dockerfile
Replicas:     1

Created satusky.toml

Generated satusky.toml

[app]
  name       = "my-api"
  port       = 8080
  cpu        = "0.5"
  memory     = "256Mi"
  dockerfile = "Dockerfile"
  replicas   = 1

Field reference

Field	Type	Description
name	string	The app label used to identify this deployment inside Kubernetes. Must be unique within your namespace. Changing this value after deployment creates a new deployment rather than updating the existing one.
port	integer	The container port your application listens on. This is the port Satusky routes traffic to — it must match what your process actually binds.
cpu	string	Kubernetes CPU request. Written in standard Kubernetes notation: "0.5" is 500 millicores, "1" is one full core.
memory	string	Kubernetes memory request. Use SI suffixes: "256Mi", "512Mi", "1Gi".
dockerfile	string	Path to the Dockerfile, relative to the project root. If your Dockerfile is in a subdirectory, use "docker/Dockerfile".
replicas	integer	The initial replica count for this deployment. You can scale independently after deploy via 1ctl deploy scale or the autoscaler.

Multiple environment configs

For projects deployed to more than one environment, maintain a config file per environment. Use --config <name> to name them:

1ctl init --config staging     # writes satusky.staging.toml
1ctl init --config production  # writes satusky.production.toml

Then pass --config to any command that reads the config file:

1ctl deploy --config staging
1ctl deploy --config production

A typical repo layout:

my-api/
  Dockerfile
  satusky.toml             ← local/default
  satusky.staging.toml
  satusky.production.toml

Each file can differ in cpu, memory, replicas, and any other field. The name field should stay the same if you want each environment to be tracked as the same logical app under a different namespace, or differ if you want fully independent deployments.

How deploy uses satusky.toml

When you run 1ctl deploy, the CLI:

1. Reads satusky.toml (or the named config via --config).
2. Resolves the deployment by app name and namespace.
3. Sends the merged deployment spec to the backend upsert flow.

The API then schedules the build and rolling update on your cluster. 1ctl does not need Docker or kubectl locally — the build and scheduling happen entirely on the Satusky backend.