dibbla export

Take everything an app keeps on Dibbla with you — source, databases, buckets, environment and manifest — in formats other tools read, with a docker compose sketch that runs it locally.

dibbla export writes everything an app keeps on Dibbla into one directory, in formats other tools already read. Nothing in it is Dibbla-specific except the dibbla.yaml you wrote yourself: the source is a git repository, the databases are pg_dump archives, the buckets are plain files, the environment is dotenv, and a docker-compose.yml runs the whole thing on a laptop.

It is the exit path — moving to another host, or keeping a complete offline copy — and it is read-only: the app keeps running on Dibbla exactly as before.

dibbla export my-app                       # → ./my-app-export/
dibbla export my-app --out /tmp/my-app     # elsewhere (must be empty or absent)

What the directory contains

An app without version control gets no source/; the inventory and the README say why. Databases and buckets are the ones bound to this app (--deployment <alias> when they were created) — org-wide ones are not exported, because they may serve other apps.

Secrets

An export carries every secret by name, never its value. A secret is write-only on Dibbla — no Dibbla API, CLI command or MCP tool returns its value, and an export is no exception. The env/ files list every name the app reads, with a blank to fill in where a secret is:

# Exported from Dibbla — app my-app
# Secret values are not part of an export: Dibbla never hands out a secret's value. Fill in the blanks.
# Platform-generated values (DATABASE_URL_*, STORAGE_*, DIBBLA_*) point at Dibbla and are
# commented out; docker-compose.yml sets local replacements.

# deployment secret; value not exported
API_KEY=
# DATABASE_URL_APPDB=  (platform-generated; value not exported)
LOG_LEVEL=debug

Plain variables — the ones in dibbla.yaml or passed with -e — keep their values. Platform-generated names (DATABASE_URL_*, STORAGE_*, DIBBLA_*) are written as comments because they point at Dibbla; the compose file sets local replacements. The values of your own secrets are the ones you hold where each was issued — the provider’s dashboard, your password manager — and you set them wherever the app runs next. Reading the environment needs the deploy roles, the same rule as env pull.

--include-secrets no longer exists as an option: a script that still passes it is refused (exit 5) before anything is written, with the reason.

Run it locally

cd my-app-export
docker compose up --build

• Postgres starts on localhost:5432 (postgres/postgres) and restores every dump in databases/ the first time its pgdata volume is created. DATABASE_URL_* points at it with sslmode=disable.
• MinIO starts on localhost:9000 (console on 9001, minioadmin/minioadmin); a one-shot minio-seed service mirrors buckets/ into it. STORAGE_* points at it.
• Public services are published from localhost:8080 upwards, in name order. ${DIBBLA_SVC_*} variables are set to plain compose service names.

Not there, because Dibbla did them in front of the app: login and the X-User-* headers, custom domains and TLS, scheduled jobs. The compose file is a starting point — adjust images, ports and resources to taste.

Take it somewhere else

• Source — source/ is a normal git repository; add a remote and push.
• Databases — pg_restore --no-owner --no-privileges -d <db> databases/<name>.dump into any PostgreSQL 15 or newer.
• Buckets — copy buckets/<name>/ to any S3-compatible store (aws s3 sync, mc mirror, rclone); the directory layout is the object keys.
• Configuration — dibbla.yaml names the services, ports and inline environment; env/ names the rest.

$dibbla export my-app
📦 Exporting my-app → my-app-export
   Source
   Databases
     appdb → databases/appdb.dump
   Buckets
     uploads: 128 object(s), 41.0Mi
   Environment
     env/app.env: 6 variable(s), 3 secret name(s)
✅ Exported my-app to /home/you/my-app-export
   source: source (a1b2c3d)
   databases: 1, buckets: 1, env files: 1, manifest: dibbla.yaml (source)
   secret values are not part of an export (write-only on Dibbla); env/ lists the names
   Start it locally: cd my-app-export && docker compose up --build  (see README.md)

After the organization is closed

Closing an organization (Portal → organization → Close Organization) does not delete it at once. Its apps stop and every change is refused, and for 30 days the organization’s owners and admins can still run dibbla export for each app and get the same export as the day before — source, databases, buckets, environment and manifest. The portal and the console show the date the window ends. When it has passed, the apps, databases, buckets, source and members are deleted.

Inside the window nothing else answers: a deploy, a log read, a database query or a member invitation is refused with ORGANIZATION_TERMINATED, and so is an export by a developer or viewer. An owner can reopen the organization from the same page; the apps start again with the replica counts they had.

Exit codes

See also

• dibbla clone — the source alone, as a working folder.
• dibbla env pull — the environment alone, into .env.local.
• dibbla db dump — one database alone.