Skip to main content

apply

apply a computesphere.yaml manifest

🚀 Apply a computesphere.yaml manifest.

A manifest describes one or more resources — a service and its deployment, datastores, and so on — and apply creates them in one shot, resolving dependencies between them. It is the fastest way to deploy an app: unlike service create (which only writes a bare service definition), a manifest also carries the deployment (image, port, tier, env vars), so you get a running service, not a stub.

The manifest is sent to the server as-is, so snake_case fields like build_source always bind correctly.

Resources are scoped to a project and an environment — pass --project and --environment (or set defaults so you can omit them).

A version-2 manifest can also declare its own project and environments, and each environment can set group-level variables and secrets that every service in that environment inherits (a service's own env_vars override the same key). Secrets are declared with { secret: true } (the value is set out of band) or pulled from another service with fromService — never written in plaintext, and re-applying never overwrites a value set elsewhere.

By default a failed resource doesn't stop the others (partial success); use --atomic to roll the whole batch back if anything fails.

When a manifest creates a single service, apply then waits for it to reach Running and prints its URL (like fly deploy). Use --no-wait to return as soon as the resources are created; --wait-timeout bounds the wait (default 5m). Updating an existing service (re-apply) reports updated/unchanged and is idempotent — re-applying the same manifest creates nothing new.

This command supports reading input from a file. Files can be supplied via the --file flag or piped into the command.

Example of file structure
{}

Usage​

csph apply [flags]

Options​

Command Specific​

--atomic
roll every resource back if any fails (all-or-nothing)
--dry-run
validate the manifest without creating anything
--environment <string>
environment ID

-f, --file <string>

specify a payload file [json|yaml], has precedence over other flags
--no-wait
return as soon as resources are created; don't wait for the deployment to be running
--project <string>
project ID

--wait-timeout <duration> (default "5m0s")

how long to wait for the deployment to reach Running

Formatting​

For more information about formatting options, see Formatting.

-o, --output <string>

output format: [table|plain|csv|json|yaml]

Inherited​

--config <string>
config file (default is $HOME/.config/computesphere/configuration.yaml)
--debug
enable debug logging

-h, --help

show this help message

-i, --interactive

run interactively (prompts, pickers, table browser)
--log-level <string>
log level: [trace|debug|info|warn|error|fatal|panic|disabled||api]
--no-color
disable color output
--no-input
disable interactive mode

Examples​

# validate a manifest without creating anything
> csph apply --file computesphere.yaml --dry-run

# apply into a project + environment
> csph apply --file computesphere.yaml \
--project <project-id> --environment <environment-id>

# all-or-nothing: roll back every resource if any fails
> csph apply --file computesphere.yaml \
--project <project-id> --environment <environment-id> --atomic

# a self-describing manifest: project, an environment with group-level
# variables/secrets every service inherits, and the services themselves
> cat computesphere.yaml
version: "2"
project:
name: acme
environments:
- name: production
variables:
LOG_LEVEL: info
secrets:
STRIPE_KEY:
secret: true
services:
- name: api
type: web-service
image: acme/api:latest
port: 8000
> csph apply --file computesphere.yaml

# a service that builds from source instead of a prebuilt image
> cat computesphere.yaml
version: "2"
services:
- name: api
type: web-service
build_source: git
runtime_type: docker
git_url: https://github.com/acme/api
branch: main
dockerfile: ./Dockerfile
build_args:
NODE_ENV: production
env_vars:
LOG_LEVEL: info
port: 8000
> csph apply --file computesphere.yaml

See also​