Using the CLI

Deploying a service from a local folder

Create or update an always-on service without a Git connection.

Run gerdoo deploy in the project root; no flags are required. If no target service is selected, the CLI creates one automatically using the folder name as its name and Default as its project, and asks for confirmation once in the terminal. Pass --yes or -y to skip confirmation, for example in CI.

Override defaults with --name <name> for the service name, --project <slug|id> for its project, --private for private access, --port N for the internal port, --framework <name> as a stack detection hint and repeatable --env K=V. No plan selection is needed: resources are limited by account level and billed by actual usage.

After the first deployment, .gerdoo/service.json is saved in the project with the service ID. Subsequent gerdoo deploy runs in that folder update the same service. To target a specific service explicitly, use gerdoo deploy --service <slug-or-id>.

The CLI waits for a final state and prints build and deployment stages. If the status becomes running, it shows the service URL; if it becomes failed, it returns the recorded error.

Managing services and Docker images

Create a service from a Docker image or deploy source to an always-on service.

List services with gerdoo services or gerdoo service list, and projects with gerdoo projects. Services have no selectable plan: resources are limited by account level and billed by actual usage.

If you have an image ready, gerdoo service create --name <name> --image <image> creates the service. Use --private to avoid public exposure, --expose tcp for a raw TCP port for databases, and --port for the application’s internal port.

To turn a local folder into an always-on service, run gerdoo service deploy --name <name>. Source is uploaded, built on the runtime and run as a service. Redeploy to the existing service with gerdoo service deploy --service <slug-or-id>.

For deployments and rollback, gerdoo service builds <slug> lists builds, gerdoo service releases <slug> lists releases, and gerdoo service rollback <slug> <build-id> returns to a previous build without rebuilding. Use gerdoo service domains <slug> for custom domains and gerdoo service vars <slug> for build-time or secret variables.

Managing projects and environments

Create and manage projects (workspaces) and their environments from the command line.

A project groups a product’s services, environments and domains. List projects with gerdoo projects, and inspect one with gerdoo project get <slug|id>. Use gerdoo project create --name <n>, gerdoo project update <slug|id> and gerdoo project delete <slug|id> to create, edit and delete projects.

Each project can have multiple environments: production, staging and preview. Manage them through gerdoo project env <project> with list, create, get, update and delete. Identify an environment by name or ID; for example, gerdoo project env my-app create --type staging --branch develop.

Manage environment variables with gerdoo project env <project> vars <env>. With no additional argument it lists values; set KEY=VALUE adds or edits a value, with --build-time for build-time injection; rm KEY removes it.

List and read commands (projects, project get, env list/get/vars) accept --json to print the raw API response, which is useful for scripts and CI.

Environment variables, logs and status

Inspect service status and change settings without opening the dashboard.

All gerdoo service subcommands take a service slug or ID as a positional argument. For example, gerdoo service env <slug> shows variables, gerdoo service env <slug> set KEY=VALUE adds or edits a value, and gerdoo service env <slug> rm KEY removes it. The service is recreated to apply changes.

The same operations are available under service: gerdoo service env <slug> [set KEY=VALUE | rm KEY] is equivalent to the shorthand. Alongside it, gerdoo service vars <slug> is a separate typed variable store supporting --build-time for build-time injection and --secret for masked values. Both the simple env map and typed vars store are available.

gerdoo logs <slug> --tail N shows the latest container log lines, defaulting to 200. Filter with --since, --grep and --level. gerdoo service status <slug> prints status, URL and, when running, CPU and memory usage. gerdoo service open <slug> opens the service URL in your browser.

Control lifecycle with gerdoo service stop <slug>, gerdoo service start <slug> for a stopped service, and gerdoo service restart <slug> for an in-place restart. Manual stopping uses stopped status and differs from suspension due to insufficient balance. Use gerdoo service delete <slug> for complete deletion.

Practical examples

Deploying from a local folder

The first deploy creates a new service and links the project. Subsequent gerdoo deploy runs in the same folder update that service.


gerdoo login
gerdoo deploy            # Create and deploy; --yes skips confirmation
gerdoo service status my-app
gerdoo logs my-app --tail 200

Environment variables and CI

In CI, keep your token as a secret and pass it through GERDOO_TOKEN to avoid interactive login. The --yes flag skips confirmation when creating a new service.


gerdoo service env my-app set NODE_ENV=production API_URL=https://api.example.com
gerdoo deploy
 
# CI example
GERDOO_TOKEN="$GERDOO_TOKEN" gerdoo deploy --service my-app --yes

Docker image services

Services are always on and have no selectable plan. Resources are limited by account level and billed by actual usage. Use a prepared image or turn a local folder into a service with gerdoo service deploy.


gerdoo service create --name redis-cache --image redis:7 --private
gerdoo service status redis-cache
gerdoo service logs redis-cache --tail 100

Builds, releases and rollback

Each successful deployment records a new build and release. rollback runs the previous build without rebuilding and creates a new active release.


gerdoo service builds my-app
gerdoo service releases my-app
gerdoo service rollback my-app <build-id>

Managing projects and environments

A project is a workspace for services. Each project can have several environments, each with its own variables. --json prints raw API output for scripting.


gerdoo project create --name shop --description "Online store"
gerdoo project env shop create --type staging --branch develop
gerdoo project env shop vars staging set DATABASE_URL=postgres://… --build-time
gerdoo projects --json

Variables, domains and the typed store

service vars is the typed variable store with --secret and --build-time support. service domains add shows the required DNS records, and verify verifies domain ownership after you create the TXT record.


gerdoo service vars my-app set STRIPE_KEY=sk_live_… --secret
gerdoo service domains my-app add app.example.com
gerdoo service domains my-app verify app.example.com