Dbrij Hosting Documentation

Dbrij Hosting runs your web apps, APIs, background workers and managed databases. You bring code from a Dbrij Source repository, a GitHub repository, a folder on your machine, a container image or a single file function. Hosting builds it, runs it, gives it HTTPS, and keeps its logs, deployments and backups where you can reach them.

Everything lives in a project, and a project holds services. A project belongs to a space: your personal space, or a company you are a member of. The space decides who can see the project, who can deploy it and who is billed for it. Services in one project reach each other privately, which is how an app talks to its database.

There are three ways in, and they all act on the same projects:

• The dashboard at /hosting, where the Deploy dialog reads your repository and fills itself in.
• The dbrij command line tool, which ships the folder you are standing in (see CLI reference).
• An AI assistant or coding tool connected over MCP, acting as you within your permissions (see AI assistants).

Prefer a guided walkthrough? The Hosting guide takes you from nothing to a live app step by step.

From a folder on your machine to a live HTTPS address in three commands. You need Node.js for npx.

1. Sign in. The terminal shows a short code and opens your browser. Confirm the code matches in a browser where you are signed in to Dbrij. No password ever goes through the terminal.

npx dbrij login

2. Link the folder to a service. Pick a project and a service, or create new ones. A new project asks which space it belongs to. The link is saved in .dbrij/project.json, which stays out of git.

npx dbrij link

3. Deploy. The folder is packed, uploaded and built. Before the build starts you are asked whether the service should get a public URL.

npx dbrij deploy
# Deploying shop / web
# · Packed 214 files (1.8 MB compressed)
# · Uploaded
# Deployed.
#   https://<service>.dbrij.app

Code on GitHub or Dbrij Source? Open Hosting, create a project, and choose the repository in the Deploy dialog. Pushes to the branch you pick then deploy on their own.

Every service has one source. It is set when the service is created and can be changed later in its settings.

Push to a Dbrij Source repository

A service that builds from a Dbrij Source repository deploys when you push to the branch it tracks. Nothing has to be registered on the repository: the push itself starts the build. Pushes to other branches are ignored by that service. To push with your Dbrij sign in instead of a token, run dbrij git setup once.

npx dbrij git setup   # once per machine
git push              # deploys the service that tracks this branch

A connected GitHub repository

Connect GitHub once from Hosting, then pick a repository and a branch. Dbrij puts the deploy webhook on the repository through your connected account, so you never paste a URL into GitHub. The service page shows whether pushes reach Dbrij, and a single button sets the webhook up again if it was removed or GitHub stopped trusting it.

Deploy on push, or only by hand

A repository service deploys on every push by default. Switch automatic deploys off to set a service up first and ship it by hand: the Deploy button keeps working, only the push nobody is watching is held. A service can also hold automatic deploys while its last code scan found malware.

A folder from your machine

dbrij deploy packs the linked folder and ships exactly what is on disk: no git remote, no webhook. Files matched by .gitignore and .dbrijignore stay behind, and so do installed dependencies, build output, caches and secrets (.env files, *.pem, *.key, id_rsa) whatever your ignore files say. The packed folder must be under 100 MiB compressed. Only services created for uploads can take a dbrij deploy.

A container image

Give the service an image reference and Hosting runs that image as it is, with no build step.

A function

A function is a single source file that runs on Bun, edited in the service's Code tab. Saving it is the deploy. A new function starts from a small server that answers on the port in PORT. The file can be up to 100,000 characters.

const server = Bun.serve({
  port: Number(process.env.PORT ?? 8080),
  fetch(req: Request) {
    const url = new URL(req.url);
    if (url.pathname === "/") return new Response("Hello from your Dbrij function!");
    return new Response("Not found", { status: 404 });
  },
});

Templates and empty services

A template deploys into a project in one click: it creates and deploys every service it describes. A service can also be created empty, with no source yet, to configure first; deploying it is refused until a source is added.

Staging copies

A service can have a staging mirror: a copy that builds and runs beside it with its own address. When the mirror is right, promote it and production receives the exact image you tested, without a rebuild.

How a repository is read

Pick a repository and the Deploy dialog scans it, the same way the CLI's scan_folder tool scans a folder. The scan reads only small files (package manifests, compose files, Dockerfiles), never the whole tree, and offers each deployable directory as a choice. A directory counts as an app when it holds one of: package.json, go.mod, requirements.txt, pyproject.toml, Pipfile, Cargo.toml, pom.xml, build.gradle, build.gradle.kts, Gemfile, composer.json, mix.exs, deno.json, or a .NET project or solution file (.csproj, .fsproj, .vbproj, .sln). It looks up to three folders deep and skips folders such as node_modules, dist, test, docs, examples and scripts.

For each app it suggests a name, the framework, a port and a role, and says when an app cannot run on Hosting at all (a mobile app, for example).

Monorepos

A repository whose root organises rather than runs (a pnpm-workspace.yaml, or a root package.json with a workspaces field) is treated as a workspace. Each app inside it is offered on its own. Set the service's Root directory to the app's folder, for example apps/web.

When that app uses sibling workspace packages (pnpm, npm or Yarn workspaces, Turborepo or Nx), Dbrij Pack installs the whole workspace from the repository root, then builds and starts only that app. No Dockerfile is needed. Folders that are not part of a JavaScript workspace build on their own. See How builds work.

While the new builder rolls out, the Deploy dialog may still mark such an app as needing a Dockerfile, and a service not yet on the new builder still needs one. A Dockerfile that copies the whole repository works on every builder. Directories that carry their own Dockerfile are always safe to pick. A service can point at a named Dockerfile, such as Dockerfile.web, with its Dockerfile path.

Databases the code expects

The scan also suggests managed databases, from compose service images or from dependencies:

How a service builds

In order of preference:

• A Dockerfile path you set. Built as written, with the whole repository as its context.
• Static site mode. Set the output folder (for example dist). A site with a package.json is built first; plain HTML is served as it is. Hosting then serves that folder itself, with single page app fallback. No Dockerfile needed. Choosing Static site is an explicit choice, so a leftover Dockerfile in the folder does not take over.
• A Dockerfile. A file named Dockerfile in the root directory, built as written.
• Dbrij Pack. With none of these, Dbrij Pack works out the language, framework and package manager and builds it for you. You can set the install, build and start commands here or in a dbrij.json file. See How builds work.

When a dbrij.json file in the app folder sets the install, build or start command, the file wins over the same setting here, because the file is reviewed in pull requests like the rest of the code.

The release command

A release command runs once per deploy, never once per copy, so two copies can never migrate one database at the same time. If it exits with an error the deployment fails and the previous version keeps serving. Before it runs, every PostgreSQL, MySQL and MongoDB database in the project is backed up, and the command waits for those backups to land. The newest three of these pre release backups are kept per database.

Deployment states

When a build fails, Hosting reads the log and writes what went wrong in plain words, the log lines it matched and what usually fixes it. It also says whose side the problem is on: on our side, where pressing Deploy again is the fix, or a fix in your repository. When the fix is a setting Hosting can change (a different install command, for example), the deployment offers to apply it and deploy again.

Your first deploy may ask you to verify a payment method with a small one time charge. A paid Hosting plan already counts as verified.

When a service has no Dockerfile, Dbrij builds it with Dbrij Pack, the builder behind Hosting. Dbrij Pack looks at the files in the app folder, works out the language, the framework and the package manager, and writes a build recipe for it. The build log says what it found in one short line.

A Dockerfile always wins. When the folder has one, or the service points at one, it is built exactly as written and Dbrij Pack is not used. The one exception is Static site: choosing it in Settings is an explicit choice, so a leftover Dockerfile does not take over.

Dbrij moves builds over to the new builder gradually, so what this page describes reaches every build as it rolls out. Until then a service builds the way Builds and detection describes.

Stacks it knows best

Gleam, C and C++ projects and start.sh scripts also build. A few kinds of project Dbrij recognises but does not build on its own (Scala with sbt, Clojure, Haskell, Swift, Dart and Flutter, Zig, Crystal, OCaml, Nim, Erlang with rebar3, Perl, R and Julia): the build stops at once and says to add a Dockerfile, which Dbrij then builds as written. If a stack needs something unusual, set the commands in dbrij.json or add a Dockerfile.

Choosing the app in a bigger project

Set Root directory to the app's folder. When that folder belongs to a larger build (a Cargo workspace, a Maven or Gradle build with several modules, or a .NET project that uses projects beside it), Dbrij Pack builds from the root of that build and starts only your app. When a project holds several apps and nothing says which one to start, the build stops and names them; choose one with a variable in Settings:

Where builds fetch from

Runtimes and packages come from Dbrij's own mirror and local package caches, so an outage somewhere else does not stop a deploy: Node, Python, Go, PHP, Ruby, Java, Rust, Erlang and Elixir, .NET and Deno themselves, and packages from npm, PyPI, Go modules, Maven Central and the Gradle plugin portal, crates.io, RubyGems, Hex and NuGet. Your project's own registry settings, such as a private registry in .npmrc, a private gem source in the Gemfile or a NuGet.Config, still win.

Repeat builds are faster

Each service keeps its own build cache. A repeat build reuses every step whose inputs did not change, so the second deploy is faster than the first.

Build variables

A service's variables reach the build as well as the running app, so values such as VITE_ and NEXT_PUBLIC_ ones are baked in at build time. Change one and deploy again to rebuild with it.

Build logs never show variable names: the log says only how many variables reached the build. Any variable value six characters or longer that the build prints is replaced with [hidden]. A few plain setting words stay visible because they fill every log: production, development, staging, preview, localhost, enabled and disabled.

The build settings file

To keep build settings with the code, add a file named dbrij.json at the root of the app folder (the service's Root directory). It must sit at the root, not inside the .dbrij folder: once a folder is linked, its .dbrij folder is ignored by git, so a file there would never reach the repository. The file is read when Dbrij Pack builds the service, so it does nothing next to a Dockerfile.

{
  "$schema": "https://dbrij.com/schemas/dbrij.json",
  "runtime": { "node": "22" },
  "buildCommand": "npm run build",
  "startCommand": "node dist/server.js"
}

The $schema line is optional. Editors read it to autocomplete the keys and check their values.

A key written in full wins over its short form: deploy.startCommand over startCommand, for example. A command written in dbrij.json wins over the same setting in the service's Settings, because the file is reviewed in pull requests like code. If the folder holds both a dbrij.json and an older build settings file, dbrij.json is used and the log says a second file was ignored.

Monorepos

Set the Root directory to the app's folder, for example apps/web. For a JavaScript workspace (pnpm, npm or Yarn workspaces, Turborepo or Nx) where that app uses sibling workspace packages, Dbrij installs the whole workspace from the repository root, then builds and starts only that app. No Dockerfile is needed. Other folders build on their own.

Static sites

Choose Static site in Settings with an output folder, or set staticOutput in dbrij.json. A site with a package.json is built, then the folder is served with single page app fallback, so a link to any route opens the app. Plain HTML is served as it is.

When a build fails

The diagnosis says whose side the problem is on. On our side means something in Dbrij failed, not your code: press Deploy again. Anything else names the fix to make in your repository.

Licences

Dbrij Pack is MIT licensed. It includes third party code under that code's own licences, and those notices ship with the builder.

Site or API

A web service can say what it is: a site (pages people visit, with the page and search tools shown) or an api (endpoints for apps, with those tools hidden). Left unset, Hosting decides from what the service's root actually returns. What you declare always wins.

Background workers

Turn a web service into a worker from its settings, or create one as a worker. A worker has no health probe on a port, because it opens none; a worker that keeps crashing still shows in its restart count. Turning worker mode on requires removing the custom domains first, and drops the public URL.

Database engines

Databases are available on paid plans. See Databases for connections, backups and restores.

Persistent volumes

A web service can mount a persistent disk at an absolute path. A service with a volume runs a single copy, because a disk can only be attached in one place. Disks can grow but never shrink. Detaching a volume keeps the disk, so attaching it again finds the data.

Each service has its own environment variables. They are encrypted at rest, and only people who can operate the service see their values. In the browser the values appear only after you confirm who you are.

On a service that has deployed before and is not stopped, changing its variables starts a new deploy so the app picks them up. Two people editing the same variables in the browser cannot overwrite each other: a save based on an older copy is refused instead of overwriting the newer one.

From the command line

npx dbrij env                     # list the names (values stay hidden)
npx dbrij env add API_URL=https://api.example.com
npx dbrij env rm OLD_FLAG
npx dbrij env pull .env.local     # write them to a file (default .env.dbrij)

dbrij env add and dbrij env rm change only the names you give, merged on the server, so a change someone else made in the meantime is kept. dbrij env pull writes a file readable only by you; it holds real secrets, so keep it out of git.

Linking Dbrij Secrets

A service can also read a Dbrij Secrets project. Link it from the Connections tab of the Secrets project, naming the environment (and optionally a folder). The service then runs with the linked secrets underneath its own variables: on a name both set, the service's own variable wins. The variables tab shows which Secrets project and version the last deploy used. A change to the linked secrets redeploys a running service, and when a deploy with new secrets fails, the service is held at the version that last worked. See the Secrets docs.

Giving a database to an app

A database's connection string goes into an app's variables from Dbrij to Dbrij, without you copying it. The default name is DATABASE_URL for PostgreSQL and MySQL, MONGODB_URI for MongoDB and REDIS_URL for Redis.

The port

Your app listens on the service's port, which Dbrij also passes in the PORT variable. A new service uses 8080 unless you or the scan set another. Read PORT rather than hard coding a number and the two can never disagree.

Health checks

Because new copies take traffic only when they answer, a deploy replaces the old version without sending visitors to an app that is still starting. Hosting also probes every running web service from outside about every five minutes; those probes feed the uptime charts and automatic rollback (see Logs and rollbacks).

Your public URL

A web service gets a free address on dbrij.app when you switch it on, from the dashboard, from dbrij url, or by answering yes when dbrij deploy asks. It is never created on its own, because creating it issues a certificate for that name. The certificate can take a minute on a brand new name; until then the link shows as securing.

Always HTTPS

Services created now redirect plain HTTP to HTTPS for every name whose certificate is live. A name joins the redirect only once its certificate works, so visitors are never sent to a certificate error.

Add a domain you own to a web service from its Domains tab. A service takes up to 3 domains; the www companion of a root domain comes free and does not count. Domains bought on Dbrij are set up for you: see the Domains docs.

The one record you add

example.com        A      @      <the address shown in the Domains tab>
app.example.com    CNAME  app    <service>.dbrij.app

Two level endings such as .com.ng and .co.uk are recognised: acme.com.ng is a root domain and gets the A record.

Verification

Hosting checks every few minutes, and on demand when you press check. It asks the domain's own authoritative nameservers rather than a cache, so a record you just fixed counts as soon as it is published. A domain passes when it has a CNAME to your service, or when every A record points at Dbrij. If any A record points somewhere else (a leftover from a previous host, or a registrar's forwarding service), the Domains tab names it, because visitors would land on that server part of the time.

HTTPS

A certificate is issued once the service has deployed at least once: until then there is nothing to answer the certificate check, and the domain says to deploy first. It puts itself right after the first deploy.

www and redirects

Adding a root domain also adds its www name, redirecting to the root, so visitors who type www arrive. Any live domain can instead redirect permanently to another live name of the same service, for example www.example.com to example.com or the reverse.

Limits

Custom domains are included on every plan. Each plan also caps how many domains can wait connected but not yet attached to a service (see Scaling, plans and limits). A name on dbrij.app cannot be added as a custom domain, and a domain can serve only one service at a time.

Build logs

Every deployment keeps its build log, and the release command's output when there is one. Variable names never appear in a build log, and values the build prints are replaced with [hidden] (see How builds work).

npx dbrij logs --build            # the latest deployment
npx dbrij logs --build a1b2c3d4   # a deployment by the id prefix the CLI prints

Runtime logs

Runtime logs are what the running service prints, read from its newest copy: up to 1,000 lines. Ask for the previous run to read the output of the copy before the current one, which is where a crash shows its error.

npx dbrij logs

Searchable history

On plans that keep log history, every service's output is collected about every half minute and kept for the plan's number of days. A day can be searched by time range, by level (all, warnings, errors) and by text or a regular expression, up to 1,000 lines a page, and downloaded as plain text one day at a time. Days follow Lagos time. Plans without history show the live output of the newest copy only.

Rollbacks

A rollback puts a previous successful build back without rebuilding it. With no argument the CLI goes back to the build before the one running now; give an id prefix to choose.

npx dbrij rollback            # the build before this one
npx dbrij rollback a1b2c3d4   # a specific deployment

Automatic rollback

Switch on automatic rollback and Hosting puts the previous build back when a deploy takes a healthy site down. It acts only on clear evidence: the site was healthy before the deploy, enough outside probes ran after it, the failure lasted rather than blipped, and a known good build exists. It watches the first 20 minutes after a deploy; after that a failure is treated as an outage, not a bad release.

Restart, stop and start

Restart runs the current build again without rebuilding. Stop takes the service down and start brings it back.

A scheduled job runs a command on a schedule: a nightly cleanup, an hourly report, a reminder email every Monday at nine. Add one in the service's Jobs tab. Web services and background workers can have jobs; databases and static sites cannot.

Each run is its own short lived copy of the service: the version that is live when the run starts, with the service's variables, size and outbound address, but no port and no URL. That is the difference from a scheduler inside your app. A deploy replaces the app's running copies, so a task inside them can be cut off halfway, run twice while the old and new copies overlap, or be missed in the gap. A scheduled job is untouched by a deploy: the next run simply uses the new version, and a run that is going finishes on the version it started with.

Choosing when it runs

Pick every five minutes, hourly, daily at a time, or weekly on a day at a time. For anything else choose Custom and type a cron expression: five parts, for the minute, the hour, the day of the month, the month and the day of the week, where a star means every one. 30 2 * * 1 is 02:30 every Monday and */15 * * * * is every 15 minutes. The form shows the schedule in words and its next three runs as you type. A seconds part and "run at start up" are not supported.

Every job has its own timezone, Africa/Lagos unless you choose another, and the schedule is read on that clock. A run missed while a machine was briefly down still starts if it is less than 5 minutes late.

How a run behaves

Stopping the service pauses its jobs, and starting it lets each one follow its own switch again. A suspended service's jobs are paused too. Deleting the service deletes its jobs. A job does not see a disk attached to the service: give it the data another way, for example through the database.

Limits by plan

Jobs are included in the Starter, Pro and Reserved plan prices. If a plan changes to one that holds fewer, the oldest jobs keep running and the rest pause, with the reason on each, until the plan covers them again.

Shutdown window

When a deploy, a restart or a stop replaces a running app, the app is told to stop and gets a moment to finish what it is doing before it is ended. That moment is 30 seconds unless you change it in the service's Settings; paid plans can raise it to 10 minutes. It only helps an app that listens for the stop signal (SIGTERM) and wraps up; one that ignores it is ended at the same moment either way.

Create a database as a service in a project. It starts at once, with its own disk, and is reachable privately by the other services in the project. Each engine has a memory floor its settings will not go below.

Connecting

The database's page shows its host, port, user, password, database name and a ready made connection URL. Only people who can operate the database see the password. Use the link to an app (see Variables and Secrets) and the URL goes straight into the app's variables.

Public networking is off by default. Switching it on gives the database a public host and port, for a SQL client or an app running on your laptop. It puts the database on the internet protected only by its password, so switch it off when you are done.

Backups

Backups cover PostgreSQL, MySQL and MongoDB. Redis is a cache and has no dump based backups here. A backup can be downloaded. Switching nightly backups off is always allowed, even when a plan has lapsed.

Restoring

A restore loads a backup into the same database and replaces what is there: anything written since the backup is lost. Only one load (a restore or an import) runs into a database at a time; another is refused until it finishes or is cancelled. A load in progress shows its progress, and a load that hangs can be cancelled or started again from its stored dump.

For the length of a load, the database is sized up within your plan, and its memory and processor go back afterwards. A size you changed by hand is never overwritten.

The restart watchdog

If the database restarts in the middle of a load, the connection the loader holds is dead and it would wait forever. A watchdog checks every 30 seconds how long the server has been up; when that is shorter than the load has been running, it stops the load with a clear error instead of leaving it hanging. Start it again from the database's backups list.

On Reserved

On the Reserved plan PostgreSQL runs as three copies with a standby ready, and promotes one on its own if the primary is lost. MySQL, MongoDB and Redis run as a single copy on every plan.

Bring an existing PostgreSQL or MySQL database into a Hosting database of the same engine. Both routes are destructive, exactly like a restore: the target is replaced by what the source holds.

From a URL

When the old database is reachable over the internet, paste its connection string (postgresql://, postgres://, mysql:// or mariadb://). Hosting connects and copies it across. The engine must match the target. These are refused before anything starts, with the reason:

• localhost and loopback addresses, which from Dbrij's side mean Dbrij's own server, not your machine.
• Private network ranges and names that only resolve inside your network (.local, .internal).
• A string with no database name or no user.

For any of those, use the route from your machine.

From your machine

When Dbrij cannot reach the old database (it is on your laptop or a private network), the import dialog gives you one command. It downloads a small script and runs it with your local pg_dump or mysqldump.

curl -fsS "<script address from the dialog>" -o "/tmp/dbrij-import-<id>.sh" && \
  DBRIJ_DB_URL="postgresql://USER:PASSWORD@localhost:5432/DATABASE" bash "/tmp/dbrij-import-<id>.sh"

curl -fsS "<script address from the dialog>" -o "/tmp/dbrij-import-<id>.sh" && \
  DBRIJ_DB_USER=USER DBRIJ_DB_NAME=DATABASE bash "/tmp/dbrij-import-<id>.sh"

Copy the exact command from the dialog: it carries your import's own address and token. For MySQL, DBRIJ_DB_HOST and DBRIJ_DB_PORT default to 127.0.0.1 and 3306, and you are asked for the password.

What the script does

1. Dumps the database once to a temporary file. A dump that fails (a wrong password or database name) sends nothing.
2. Hands the upload to a background process, so you can close the terminal. Progress shows in the import dialog, or follow the log file it names. Set DBRIJ_FOREGROUND=1 to keep it attached.
3. Sends the file in numbered 64 MiB parts straight to storage. A part moving under 5 KB a second for a minute is dropped and retried.
4. Asks Dbrij to assemble the parts and checks the result is the size declared, then deletes the temporary file.

When it says it is done, go back to the dialog and press Load it in.

Resume rules

• Run the same command again to continue. Dbrij records every part that landed, and the script continues from the exact byte it reached. A dump already on disk from an earlier run is reused, not made again.
• Reopening the dialog shows the same command, so the copy on your clipboard keeps working. The command is valid for 48 hours.
• A different dump replaces the old one. If the file is remade (a new size or a new dump), the parts received so far are thrown away and the send starts over. Parts of two dumps are never mixed.
• Discard throws away what arrived and waits for another dump with the same command, good for another full 48 hours. A load already started from it is not touched.
• An import that already loaded is finished: open the dialog for a new one.
• The largest dump this route takes is 640 GB.

Scaling a service

Each service sets its copies (replicas), memory and CPU in Settings. Changing the number of copies applies live; changing memory or CPU redeploys. The settings never offer a size larger than one machine in your plan's pool can give, and a database engine has a memory floor. A service with a volume runs one copy. On Reserved, a running web service keeps at least two copies on different machines.

Usage is metered on what services actually consume, sampled every five minutes, against the plan's monthly allowance. On paid plans usage past the allowance is billed at the rates below; the free plan stops instead. When the free allowance runs out the app is paused, and it runs again once usage falls back under the allowance.

Plans

• Free. A real app to try things on, running until the free allowance runs out.
• Starter. An app and its database, in production, for the price of lunch.
• Pro. For teams running real workloads across several projects.
• Reserved. For a service whose going down is a headline. Reserved machines, nothing running as a single copy..

Database operations are console queries (one each), "what is using this database" reads (three each) and process stops (one each). Paid plans bill each operation past the allowance; the free plan stops.

Platform ceilings

Plans narrow these; nothing goes past them.

What Reserved guarantees

• Every web service runs at least two replicas, on different machines, enforced by the platform.
• A machine cannot be taken out of service while it holds the last healthy replica of your app.
• Deploys replace a replica only after its replacement is answering, so a release is not an outage.
• Your workloads run on a pool of machines kept for Reserved customers only, never on the shared tenant pool.
• PostgreSQL runs as three copies with a standby ready, and promotes one on its own if the primary is lost.
• Databases backed up nightly and kept for a year, with a restore you can run yourself.
• Runtime output of every service kept for 90 days, searchable by day, hour and text, and downloadable a day at a time.
• Deployed code is scanned before it goes live, and a failing deploy rolls back on its own.

What Reserved does not do yet

• MySQL, MongoDB and Redis run as a single instance. Failure or planned maintenance means minutes of downtime while they restart. Only PostgreSQL is replicated.
• Our provider has no availability zones: one data centre per location. Surviving the loss of a building means machines in a second location, and how many the fleet has is shown in the platform console rather than promised here.
• Where the fleet is in one location, recovery from losing it is a restore from backup, measured in hours.
• A web service with an attached disk cannot be spread. Disks belong to one location and cannot follow a pod to another.

When a payment provider, a bank or a partner asks for the address your app calls them from, Hosting has one stable outbound address for that. Your services' outbound calls leave from it.

The address is not printed on every page. Someone who manages the project asks for it and says what it is for (for example, the provider being whitelisted). Dbrij keeps that record, so if the address ever has to move, everyone who whitelisted it is told first. Once released, the project can measure it again from every machine, to confirm calls really leave from that address, and can withdraw its access at any time.

The dbrij package runs with npx dbrij, or install it globally with npm i -g dbrij. Commands that act on a service use the folder's link, so run dbrij link first.

The CLI watches a deploy for up to 25 minutes. Time spent waiting for a free plan build slot does not count. Stopping the watch never stops the deploy.

An AI assistant or coding tool that speaks MCP can deploy and run your apps for you. It acts as you: your permissions, your company role, your plan's limits and the payment check all apply exactly as they would to you. Two servers offer the tools.

{
  "mcpServers": {
    "dbrij": { "command": "npx", "args": ["-y", "dbrij", "mcp"] }
  }
}

Reading

Deploying and changing

The hosted server adds github_status, list_github_repos, scan_github_repo, scan_source_repo and deploy_github_repo. The local server adds scan_folder, which reads a folder the way the Deploy dialog reads a repository, and deploy_folder, which packs and deploys it by the same rules as dbrij deploy.

Paying, resizing and deleting wait for you

An assistant can never spend money or delete anything by itself. Changing a plan, buying a domain, resizing a service, deleting a service or project, restoring a backup and removing a domain are filed as requests. You approve or turn them down on Dbrij, from a link and a notification on your phone, never in the chat. A request you do not decide expires after 15 minutes.

What an assistant never sees

Variable values and database passwords are never returned to an assistant, only the names of variables. Logs are passed to it marked as untrusted, and it is told never to act on instructions found inside them. When a build diagnosis says to stop, the assistant stops and tells you.

Dbrij Pack turns your code into a container image without a Dockerfile, for teams that run their apps anywhere. Send a folder or a git repository and get an OCI image back: in your space’s own Dbrij registry namespace, or pushed to your own registry. On paid plans every image comes with a list of what is inside it (an SBOM) and provenance, and on Pro the provenance is signed. Pack is the same builder that builds your Hosting services; here it is billed on its own, in naira, as build minutes.

Builds use local package caches: runtimes, packages and base images come from Dbrij’s own copies, so an outage somewhere else does not stop a build. Builds for your Hosting services are included in every Hosting plan and never charged here; Free Hosting has a fair use limit of 300 build minutes a month.

Pack is opening space by space. Until it is open, every route answers: “Dbrij Pack builds are not available yet. They open soon.” The console lives in Hosting, under Builds. A walkthrough is in the Pack guide.

Signing in

Every route answers a signed in person (the console and dbrij login) or a Dbrij API key. Make a key in Hosting, Builds, API keys: it carries pack:build (start and cancel builds, upload folders) and pack:read (read builds, logs, SBOMs, provenance and signatures), and nothing else. Send it as Authorization: Bearer. Plans, webhooks and the pull credential are managed signed in. Every success body is wrapped in { "success": true, "data": … }, and a refusal carries a message written to be shown to a person.

The API

curl -X POST https://api.dbrij.com/api/v1/pack/uploads \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": {
    "uploadUrl": "https://…",
    "sourceKey": "pack/uploads/…tar.gz",
    "maxBytes": 524288000,
    "expiresAt": "2026-11-08T10:15:00.000Z"
  }
}

curl -X POST https://api.dbrij.com/api/v1/pack/builds \
  -H "Authorization: Bearer $DBRIJ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"gitUrl":"https://github.com/acme/web.git","gitRef":"main","tag":"web:1.4.0"}'

{"gitUrl":"https://github.com/acme/web.git","gitRef":"main","tag":"web:1.4.0"}

{
  "success": true,
  "data": {
    "id": "6f1c2a4e-9b0d-4c6e-a1f2-3d4b5c6d7e8f",
    "status": "succeeded",
    "source": "git",
    "gitUrl": "https://github.com/acme/web.git",
    "gitRef": "main",
    "rootDir": null,
    "target": "dbrij",
    "imageRef": "registry.dbrij.app/pack-3f2a9c1b/web:1.4.0",
    "digest": "sha256:4f1c9a2b7d0e…",
    "builder": "standard",
    "stack": "node/next",
    "path": "automatic",
    "trigger": "action",
    "label": "Add the pricing page",
    "createdAt": "2026-11-08T10:00:00.000Z",
    "startedAt": "2026-11-08T10:00:04.000Z",
    "finishedAt": "2026-11-08T10:02:41.000Z",
    "seconds": 157,
    "billedMinutes": 3,
    "error": null,
    "diagnosis": null,
    "hasSbom": true,
    "hasProvenance": true,
    "hasDockerfile": true,
    "signature": {
      "by": "dbrij",
      "keyId": "dbrij-pack-2026",
      "fingerprint": "9c1e…",
      "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n…",
      "algorithm": "ecdsa-p256-sha256",
      "signedAt": "2026-11-08T10:02:42.000Z"
    },
    "createdBy": { "id": "…", "name": "Ada" }
  }
}

curl -X GET https://api.dbrij.com/api/v1/pack/builds \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": { "builds": [ { "id": "6f1c…", "status": "building", … } ], "next": "6a0b…" }
}

curl -X GET https://api.dbrij.com/api/v1/pack/builds/:id \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": {
    "id": "6f1c2a4e-9b0d-4c6e-a1f2-3d4b5c6d7e8f",
    "status": "succeeded",
    "source": "git",
    "gitUrl": "https://github.com/acme/web.git",
    "gitRef": "main",
    "rootDir": null,
    "target": "dbrij",
    "imageRef": "registry.dbrij.app/pack-3f2a9c1b/web:1.4.0",
    "digest": "sha256:4f1c9a2b7d0e…",
    "builder": "standard",
    "stack": "node/next",
    "path": "automatic",
    "trigger": "action",
    "label": "Add the pricing page",
    "createdAt": "2026-11-08T10:00:00.000Z",
    "startedAt": "2026-11-08T10:00:04.000Z",
    "finishedAt": "2026-11-08T10:02:41.000Z",
    "seconds": 157,
    "billedMinutes": 3,
    "error": null,
    "diagnosis": null,
    "hasSbom": true,
    "hasProvenance": true,
    "hasDockerfile": true,
    "signature": {
      "by": "dbrij",
      "keyId": "dbrij-pack-2026",
      "fingerprint": "9c1e…",
      "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n…",
      "algorithm": "ecdsa-p256-sha256",
      "signedAt": "2026-11-08T10:02:42.000Z"
    },
    "createdBy": { "id": "…", "name": "Ada" }
  }
}

curl -X GET https://api.dbrij.com/api/v1/pack/builds/:id/logs \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": { "logs": "==> Building web:1.4.0\n==> 12 build variables passed to the build. Names and values are hidden.\n…", "live": true }
}

curl -X GET https://api.dbrij.com/api/v1/pack/builds/:id/sbom \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": { "spdxVersion": "SPDX-2.3", "packages": [ { "name": "next", "versionInfo": "15.0.3", "licenseConcluded": "MIT" }, … ] }
}

curl -X GET https://api.dbrij.com/api/v1/pack/builds/:id/provenance \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": { "_type": "https://in-toto.io/Statement/v0.1", "predicateType": "https://slsa.dev/provenance/v0.2", "subject": [ … ], "predicate": { "builder": { "id": "…" }, "materials": [ … ] } }
}

curl -X GET https://api.dbrij.com/api/v1/pack/builds/:id/dockerfile \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": { "dockerfile": "FROM …\nRUN …" }
}

curl -X GET https://api.dbrij.com/api/v1/pack/builds/:id/signature \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": {
    "by": "dbrij",
    "keyId": "dbrij-pack-2026",
    "fingerprint": "9c1e…",
    "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n…",
    "algorithm": "ecdsa-p256-sha256",
    "signedAt": "2026-11-08T10:02:42.000Z",
    "payload": "eyJpbWFnZSI6…",
    "signature": "MEUCIQ…"
  }
}

curl -X POST https://api.dbrij.com/api/v1/pack/builds/:id/cancel \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": { "id": "6f1c…", "status": "cancelled", … }
}

curl -X GET https://api.dbrij.com/api/v1/pack/account \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": {
    "available": true,
    "buildNodeReady": true,
    "plan": "pack_starter",
    "planName": "Starter",
    "status": "active",
    "interval": "monthly",
    "autoRenew": true,
    "currentPeriodEnd": "2026-12-08T00:00:00.000Z",
    "graceUntil": null,
    "pinnedPriceNgnMinor": 450000,
    "usage": { "minutes": 312, "includedMinutes": 1000, "overMinutes": 0, "accruedOverageNgnMinor": 0, "periodStart": "…", "periodEnd": "…", "builds": 41, "failed": 3, "running": 1 },
    "cardVerified": true,
    "namespace": "registry.dbrij.app/pack-3f2a9c1b",
    "canManage": true
  }
}

curl -X GET https://api.dbrij.com/api/v1/pack/plans \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": [ { "id": "pack_free", "name": "Free", "priceNgnMinor": 0, "includedMinutes": 100, … }, … ]
}

curl -X POST https://api.dbrij.com/api/v1/pack/checkout \
  -H "Authorization: Bearer $DBRIJ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"plan":"pack_starter","useSavedCard":true}'

{"plan":"pack_starter","useSavedCard":true}

{
  "success": true,
  "data": { "authorizationUrl": null, "reference": "…", "charged": true }
}

curl -X POST https://api.dbrij.com/api/v1/pack/renewal \
  -H "Authorization: Bearer $DBRIJ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"renew":false}'

{"renew":false}

{
  "success": true,
  "data": { "plan": "pack_starter", "autoRenew": false, … }
}

curl -X GET https://api.dbrij.com/api/v1/pack/pull-credentials \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": { "registry": "registry.dbrij.app", "namespace": "registry.dbrij.app/pack-3f2a9c1b", "username": "robot$pack-3f2a9c1b+pull", "createdAt": "…" }
}

curl -X POST https://api.dbrij.com/api/v1/pack/pull-credentials \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": { "registry": "registry.dbrij.app", "namespace": "…", "username": "…", "password": "…", "createdAt": "…" }
}

curl -X GET https://api.dbrij.com/api/v1/pack/webhooks \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": [ { "id": "…", "url": "https://example.com/hooks/dbrij", "events": ["build.succeeded", "build.failed"], "enabled": true, "failures": 0, "lastError": null, "createdAt": "…" } ]
}

curl -X POST https://api.dbrij.com/api/v1/pack/webhooks \
  -H "Authorization: Bearer $DBRIJ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://example.com/hooks/dbrij","events":["build.succeeded","build.failed"]}'

{"url":"https://example.com/hooks/dbrij","events":["build.succeeded","build.failed"]}

{
  "success": true,
  "data": { "id": "…", "url": "https://example.com/hooks/dbrij", "events": ["build.succeeded", "build.failed"], "enabled": true, "failures": 0, "lastError": null, "createdAt": "…", "secret": "whsec_…" }
}

curl -X DELETE https://api.dbrij.com/api/v1/pack/webhooks/:id \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

curl -X GET https://api.dbrij.com/api/v1/pack/signing-key \
  -H "Authorization: Bearer $DBRIJ_API_KEY"

{
  "success": true,
  "data": { "keyId": "dbrij-pack-2026", "fingerprint": "9c1e…", "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n…", "algorithm": "ecdsa-p256-sha256" }
}

Following a build

A build is queued, then building, then succeeded, failed or cancelled. Ask for the log every two or three seconds while live is true; the console does the same every 2.5 seconds. A failed build carries a diagnosis: one sentence on what went wrong, whether it was on our side, and what to try.

while true; do
  curl -s -H "Authorization: Bearer $DBRIJ_TOKEN" https://api.dbrij.com/api/v1/pack/builds/$ID/logs > log.json
  jq -r .data.logs log.json | tail -n 5
  [ "$(jq -r .data.live log.json)" = "false" ] && break
  sleep 3
done

Webhooks

Add a webhook in Hosting, Builds, Webhooks and pulls, or with the API. When a build ends, Dbrij posts its event with the whole build as JSON. Each delivery carries X-Dbrij-Signature: sha256=…, an HMAC SHA 256 of the raw body with the webhook’s secret, like every Dbrij webhook. Check it before you trust the body.

{ "type": "build.succeeded", "createdAt": "…", "data": { "id": "6f1c…", "status": "succeeded", "imageRef": "…", "digest": "sha256:…", … } }

{ "type": "build.failed", "createdAt": "…", "data": { "id": "6f1c…", "status": "failed", "diagnosis": { "title": "…", "side": "yours", … }, … } }

{ "type": "build.cancelled", "createdAt": "…", "data": { "id": "6f1c…", "status": "cancelled", … } }

import { createHmac, timingSafeEqual } from 'crypto';

function verify(rawBody, header, secret) {
  const expected = 'sha256=' + createHmac('sha256', secret).update(rawBody).digest('hex');
  return header.length === expected.length && timingSafeEqual(Buffer.from(header), Buffer.from(expected));
}

The command line

dbrij pack is part of the dbrij command line. Sign in once with dbrij login, or set DBRIJ_TOKEN to a key in CI. The folder is packed with the same rules as dbrij deploy: what .gitignore and .dbrijignore leave out stays out.

Local builds with --local run the open source dbrij-pack tool on your machine against your own BuildKit (or Docker). They fetch runtimes and packages from their public sources, not from the Dbrij package caches, and cost no build minutes. Set DBRIJ_PACK_BIN to where the tool is, and BUILDKIT_HOST to your BuildKit.

GitHub Action

The Dbrij Pack Action runs dbrij pack build in your workflow and hands back the image reference and digest. It is published by Dbrij from its GitHub organisation as DbrijHQ/pack-action.

jobs:
  image:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - id: pack
        uses: DbrijHQ/pack-action@v0
        with:
          token: ${{ secrets.DBRIJ_TOKEN }}
          tag: web:${{ github.sha }}
      - run: echo "Built ${{ steps.pack.outputs.image }}@${{ steps.pack.outputs.digest }}"

Dbrij Source CI

In a Source CI pipeline, add a step that builds the commit. Put a key with pack:build and pack:read in the pipeline’s secrets as DBRIJ_TOKEN.

npx --yes dbrij pack build . --tag web:$DBRIJ_CI_SHA

SBOM and provenance

On paid plans every image gets an SBOM: an SPDX JSON list of every package inside it, with versions and licences. Provenance is an in toto statement in the SLSA format: which builder ran, what went in with their digests, and when. Both are attached to the image and served by the API; the console shows them under a build and downloads them as JSON.

Pack builds pass build variables as secret mounts, so no value is ever recorded in provenance or in an image layer. A build from your own Dockerfile receives its variables as build arguments, so its provenance records build arguments only in a minimal form. Use secret mounts for anything sensitive.

Checking a signature

A signed build has a signature bundle: a payload that names the image digest and the attestation digests, an ECDSA P 256 signature over the payload’s SHA 256, and the public key. Check it with standard open tools:

# Save the three files (the Signature tab of a build downloads them, or decode the API's bundle).
jq -r .data.payload bundle.json | base64 -d > payload.json
jq -r .data.signature bundle.json | base64 -d > sig.der
jq -r .data.publicKeyPem bundle.json > key.pem

# The signature. It prints "Verified OK".
openssl dgst -sha256 -verify key.pem -signature sig.der payload.json

# The payload must name the image's digest, or the signature is not about this image.
grep -c "sha256:<the image digest>" payload.json

Then check the key is Dbrij’s: GET /v1/pack/signing-key returns Dbrij’s public key and its fingerprint (SHA 256 of the key’s DER), with no sign in. A build signed with your own key from Dbrij Secrets carries your key instead.

Plans and minutes

A build counts the seconds it ran as minutes, rounded up; the large builder counts each minute twice. Paid plans keep building past the allowance and bill the extra minutes when the plan renews; the free plan stops. Prices are in naira, and the price you chose a plan at is pinned: renewals never charge more for it. Cancel stops the renewal, and the plan stays on until its paid period ends.

Limits

Dbrij Pack’s open source parts and their licences are listed on the third party notices page.