Guides

Deploying apps

What a deploy actually does, the manifest for apps with more than one service, and the version history you get whether or not you asked for it.

Your first deploy covers the happy path. This page is what to know once you deploy regularly.

What a deploy does

dibbla deploy packages the directory, builds it with the Dockerfile at its root, and rolls the result out. It is most of the directory rather than all of it: some paths are filtered on the way, and one of those filters changes what your Dockerfile can see. See what reaches the build. Three consequences worth internalising:

Your Dockerfile is the contract. There is no language detection and no generated build. If it builds locally with docker build, it will almost always build here — with one exception worth knowing before it bites you: dependency and build-output directories are regenerated in the build, not uploaded. A Dockerfile that copies a pre-built output directory or a vendored dependency tree builds locally and fails on the platform. Produce those in a build step instead.
Every deploy is a commit. The platform keeps a repository for your app; your -m message is the commit subject. Write them as you would in git.
--update is a rolling update; --force tears down first. Prefer --update. --force means downtime, and the two cannot be combined.
A governed app does not roll out the moment you deploy. If the app’s change queue is on, dibbla deploy opens a proposal that a different person approves. The maintenance agent uses that same queue — it never deploys on its own.

$dibbla deploy . --alias my-app -m "feat: add the export button" --update
 
# env vars persist across updates — pass them once
$dibbla deploy . --alias my-app -m "feat: initial deploy" -e NODE_ENV=production
 
# see what a deploy would do, without building
$dibbla preview .

A slow deploy can look like a failed one

The client holds one connection while the backend builds. Builds over about 100 seconds can return a timeout to your terminal while the build carries on and succeeds. Wait a couple of minutes and check dibbla apps list before concluding anything — and if you retry, use --update, never --force.

Apps with more than one service

One Dockerfile covers one service. When an app is a web frontend and an API and a worker, describe it in a dibbla.yaml at the deploy root:

version: 1
services:
  web:
    build: ./web
    port: 80
    public: true      # exactly one service is the public one
  api:
    build: ./api
    port: 80          # internal: reachable by the other services, not the world

Check it before you ship it. The two commands below are not the same kind of check: manifest validate is local and offline, while preview needs a login and uploads the archive to have the platform resolve it.

$dibbla manifest validate .
✓ dibbla.yaml is valid
  2 services: web (public), api
 
$dibbla preview .

Services find each other through injected DIBBLA_SVC_* variables rather than hardcoded hosts, and each gets its own logs — dibbla logs <app> --service api. The console shows them under a Services tab that only appears for multi-service apps.

preview reports more than services: it prints the effective value of every resolved setting, including whether support tickets are on and whether that came from this file or from the console switch. Every field the manifest accepts is listed in the dibbla.yaml reference.

Version history

Because every deploy is a commit, an app has a history you did not have to set up: who deployed, when, with what message, and the diff. It is in the console under Version History, and you can clone it:

$dibbla clone my-app
# …edit…
$dibbla deploy . --alias my-app -m "fix: …" --update
# deploy is how a change is saved: every deploy is one commit

That repository is where the app’s code history lives — Dibbla holds it for you, and every deploy adds to it. A local .git is fine to keep, but it is not where saving happens, and a project with no remote is not missing anything: dibbla deploy --update is the save step. git push against the managed repository is answered with 403 by design, because the repository is written by deploys. You do not need a GitHub or GitLab remote to save or share a Dibbla app.

Keep secrets out of that history

The platform strips secrets and dependency directories from the managed repository automatically and tells you what it filtered — every .env* except .env.example, which carries the names your app needs and travels with the code so a clone on another computer knows what to dibbla env pull. Add your own generated or oversized paths to .dibblaignore — a per-file size cap will otherwise fail the deploy outright. Note that .dibblaignore is a VCS filter: putting a path in it does not remove that path from the Docker build, and leaving a path out of it does not guarantee the path reaches the build either. What the build sees is decided separately, and by .dockerignore.

If your org has GitHub mirroring enabled, the same commits also land in a mirror repository, which is how a Dibbla-deployed app ends up reviewable in a place your team already uses.

Check before you deploy