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 or mix.exs. 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. An app that depends on sibling packages and has no Dockerfile of its own is flagged: building a subfolder cannot see its siblings, so that app needs a Dockerfile to deploy. 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. A file named Dockerfile in the root directory, or the path you set.
• Static site mode. Set the output folder (for example dist) and Hosting runs your build command, then serves that folder itself. No Dockerfile needed.
• Automatic detection. With neither, the language and framework are detected and built for you. You can override the install, build and start commands.

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

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.

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.

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.