Application configuration

The dashboard, CLI and repository sync submit the same versioned application specification. Export the configuration from an application, edit it in a repository or the dashboard, then review the plan before deploying.

Every file needs schema_version = 1, a name and at least one service with an image. Unknown fields are rejected. Project and environment come from the selected dashboard scope or CLI context, not from Kubernetes namespace settings inside the file.

Service settings#

Dependency ordering does not replace application retries after startup. Readiness is also separate from liveness; Hakopod does not silently turn an HTTP readiness check into a liveness probe.

Ordinary variables and secrets#

Each service has its own environment variables. Ordinary values appear in exported TOML and configuration history:

[services.web.env]
API_URL = "http://api:8080"
LOG_LEVEL = "info"

Store credentials as application-scoped secrets first, then bind their names explicitly to the services that need them:

[services.api.secrets]
DATABASE_URL = { ref = "database-url" }

These are configuration excerpts to add to existing service definitions. Secret values are write-only and do not appear in TOML, secret-list responses or revision history. Changing a secret requires a restart or deployment to refresh a container's environment. Removing a binding cannot erase a value already inside a running process.

Use the service's Environment and Secrets sections to edit these directly. Preserve the distinction even when a value has a harmless-looking name; validation cannot discover every secret disguised as ordinary text.

Resource profiles#

Requests are scheduling requirements; limits are ceilings. A profile does not reserve capacity your nodes do not have. A normal rolling update may need one additional replica. Persistent services use one replica and a Recreate update, so plan for downtime.

Storage and filesystem permissions#

Use a service volume for one persistent data directory, or named application volumes when you need explicit mounts. This excerpt defines a named volume and mounts it in an existing API service:

[volumes.uploads]
size_gib = 10

[services.api]
image = "your-registry.example/api:1"
port = 8080
run_as_user = 10001
run_as_group = 10001
fs_group = 10001
read_only_root_filesystem = true
mounts = [{ volume = "uploads", mount_path = "/app/uploads" }]
temporary_mounts = [{ mount_path = "/tmp", size_mib = 32, memory = true }]

Replace the illustrative image with your own. The image must support the selected non-root identity and writable paths. A memory-backed temporary mount counts against the container's memory limit and disappears when the pod is replaced.

Named volumes default to ReadWriteOnce. Sharing across services requires ReadWriteMany, an explicitly selected capable storage class and matching filesystem groups. Hakopod does not install a shared-storage driver for you. Existing claim size, class and access mode cannot change through an ordinary deployment.

Mounts cannot expose host directories or protected system paths. Removing a service retains its persistent claim; rolling back configuration does not rewind its data. Use Backups separately.

The full schema reference includes autoscaling, private ports, certificate mounts, approved AWS identities and exact limits.