dibbla deploy & apps

Build the current directory as a container, push it to the Dibbla platform, and manage the resulting application — env vars, replicas, CPU, memory, port, access policy.

dibbla deploy packages a directory containing a Dockerfile and ships it to your Dibbla organization. The resulting app is reachable at https://<alias>.dibbla.com.

dibbla apps is the CRUD surface for already-deployed apps: list them, change their config, or delete them.

dibbla deploy

Build and push the contents of [path] (defaults to .) as a Dibbla application.

Requirements

• A Dockerfile at the deploy root.
• The Dockerfile must expose a port and define an entrypoint.
• Authentication via dibbla login or DIBBLA_API_TOKEN.
• REVIEW.md at the deploy root, and a handbook at docs/index.md (or APP.md) whose frontmatter carries a subtitle: — non-empty, not placeholder text, and 140 bytes or fewer.

The last one is a client-side gate: dibbla deploy checks for both files and exits 1 before uploading anything. --skip-review bypasses it. See Deploy your first app for what belongs in each file.

Symlinks inside the deploy directory are followed and packaged as regular files. Symlinks whose target escapes the deploy root (including absolute symlinks like /etc/passwd) are skipped — you can’t accidentally upload host files.

Flags

Examples

# Deploy current directory using its name as the alias
$dibbla deploy -m "feat: initial deploy"
[info] deploy   deployment_id=dep_wuk1bfahjdua
[info] build    step=13/23 done name=go-build elapsed=6.5s
[info] rollout  phase=rollout-start strategy=create
[info] rollout  phase=route-done
[info] deploy   status=ok url=https://hello-world-b4687da9.dibbla.com elapsed=19.7s
 
deploy ok  ·  https://hello-world-b4687da9.dibbla.com  ·  19.7s

# Keep the .env outside the deploy root — see the guardrail note below
$dibbla deploy . \
  --env-file ../secrets/.env.prod \
  -e LOG_LEVEL=debug \
  -m "feat: initial deploy"
 
# The file seeds every var; -e wins for LOG_LEVEL

$dibbla deploy ./api \
  --alias my-api \
  --cpu 500m --memory 512Mi --port 3000 \
  -e NODE_ENV=production -e LOG_LEVEL=info \
  -m "feat: add /healthz endpoint"

# Zero-downtime redeploy of an existing alias
$dibbla deploy --update -m "fix: correct the totals query"
[info] rollout  phase=rollout-start strategy=rolling
[info] deploy   status=ok url=https://my-api-b4687da9.dibbla.com elapsed=24.1s

# Replace existing alias (causes downtime)
$dibbla deploy --force --alias my-api -m "chore: rebuild from scratch"
[info] rollout  phase=rollout-start strategy=replace

.dibblaignore

The platform keeps a server-side version-controlled history of every deploy. Use a .dibblaignore at the deploy root to filter what’s committed (it does not affect the Docker build — Dockerfile’s own COPY rules do that).

The syntax is gitignore-style — **, directory globs, and negation all work.

build/
dist/
*.tsbuildinfo
coverage/
.nyc_output/
.env
.env.local
.vscode/
.idea/
*.swp
.DS_Store
data/*.parquet
fixtures/*.bin

The platform filters the following paths out of the managed repository, regardless of .dibblaignore:

• node_modules/, dist/, .venv/, .git/
• .env* files
• *.pem, *.key

A hit is filtered with a warning, not rejected — the deploy proceeds without the file. Only the size caps stop a deploy outright.

The list ends where it is written: it matches extensions, so a key stored under a bare name — id_rsa, id_ed25519 — is not caught and does end up in the repository. Do not treat this filter as a safety net; it is a backstop for the two or three most common accidents.

dibbla deploy . --env-file ../secrets/.env.prod -m "feat: initial deploy"

Per-file and per-commit size limits are enforced server-side; oversize files cause the deploy to fail with an ErrCodeVCSFiltered error.

dibbla apps list

Print every deployed app in the org with its URL, status, and last deploy time.

$dibbla apps list
🌱 Retrieving Dibbla applications...
 
Found 3 applications:
 
ALIAS                URL                                      STATUS          LAST DEPLOYED
-----                ---                                      ------          -------------
my-api               https://my-api.dibbla.com                running         2026-04-28 14:02:11
ops-tool             https://ops-tool.dibbla.com              running         2026-04-27 09:14:38
billing              https://billing.dibbla.com               sleeping        2026-04-16 17:30:22

dibbla apps update

Change the configuration of a deployed app without a fresh deploy. At least one flag is required.

Flags

Examples

$dibbla apps update my-api -e NODE_ENV=production --replicas 2
✏️ Updating deployment 'my-api'...
 
✅ Deployment updated successfully.
 
   Alias:  my-api
   URL:    https://my-api.dibbla.com
   Status: running
   Health: ok (398ms)

$dibbla apps update my-api --cpu 500m --memory 512Mi --port 3000

$dibbla apps update my-api --require-login true --access-policy invite_only

dibbla apps restart

Trigger a rolling restart of one service, without redeploying. This is how a changed secret reaches running pods — saving a secret updates the store, but a container reads its environment only at start.

Idempotent in the sense that it always succeeds — but not a no-op: calling it twice produces two pod rollouts.

# single-service app
$dibbla apps restart my-app --service app
 
# one service of a multi-service app
$dibbla apps restart my-app -s worker

dibbla apps delete

Permanently delete an app. The alias becomes available for reuse.

$dibbla apps delete my-api
🗑️ Attempting to delete application 'my-api'...
 
? Are you sure you want to delete 'my-api'? This action cannot be undone. (y/N)
 
✅ Application 'my-api' deleted successfully

See also

• dibbla secrets — set env vars that shouldn’t appear in deploy commands, or bulk-load a whole file with secrets import without redeploying.
• dibbla db — provision a Postgres and bind a DATABASE_URL secret to your app.
• dibbla run — run a dibbla-task.yaml pipeline locally before you deploy.