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 uploads the directory, builds it with the Dockerfile at its root, and rolls the result out. 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 build here.
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.

$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.

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
# read-only: pushing is rejected — fork to GitHub if you want to share

Keep secrets out of that history

The platform strips .env, node_modules/, *.pem and *.key from the managed repository automatically and tells you what it filtered. Add your own generated or oversized paths to .dibblaignore — a per-file size cap will otherwise fail the deploy outright. Note it is a VCS filter: it does not change what the Docker build sees, which is .dockerignore’s job.

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.

Environment & secrets