The Hosting guide

Hosting runs your apps and APIs on Dbrij. You point it at a Git repository, a prebuilt image or a template, and it builds, deploys and serves the result at a live URL with automatic HTTPS. There is no Dockerfile to write unless you want one, no server to rent, and no certificate to renew.

Everything is organised into projects, and a project groups the services you deploy together: a web app, the API behind it, and the database beside them. Managed PostgreSQL and Redis spin up in one click, custom domains attach to any service, and live metrics show what every service consumes so the bill never surprises you.

A service starts from one of a few sources, and the choice only changes how the deploy begins:

• A Git repository. Connect GitHub once, or point the service at a repository on Dbrij Source. Dbrij builds it for you, and once push to deploy is connected, every push to your branch ships a fresh deploy on its own. There is nothing to register and no webhook to fail.
• A prebuilt image. If you already build images elsewhere, the service pulls and runs yours directly.
• A template. The gallery launches ready made open source tools in one click: a whiteboard, workflow automation, a blog, uptime monitoring, dashboards and a spreadsheet database.
• A function. Function services carry their code with them and expose a Code tab right on the service page.

A service page carries everything about one running unit, as tabs: Overview, Insights, Security, Deployments, Logs, Variables, Domains, Recovery and Settings. The parts you will live in:

• Deployments lists every deploy with what triggered it and its build or rollout logs.
• Logs tails the running service, and on the Reserved plan keeps 90 days of history you can search by day. Logs also sit at the top level of the rail, beside Projects, because the moment anyone wants them is an incident.
• Variables holds the environment configuration the service starts with.
• Settings covers memory, CPU and the rest. Renaming a project only changes the display name; deployed services, URLs and databases stay exactly as they are.

Deleting a service stops it serving traffic immediately, and it cannot be undone.

The Logs tab opens on the live output of the running service. On the Reserved plan it also keeps that output: every line each service writes, from every copy it runs, is collected every half minute and kept for 90 days. A restart, a redeploy or a crash no longer takes the lines with it; when a container restarts, the last output of the run that ended is kept too, so a crash can be read afterwards.

• Switch the Logs tab to History and choose a day. Only days with logs are offered.
• Narrow it with a start and end time, a search, and Errors only or Warnings and errors. A search ignores case; wrap it in slashes, like /timeout|refused/, to search by a regular expression.
• The bars show the day hour by hour, with errors in red. Click an hour to narrow the results to it.
• Results come a thousand lines at a time; Load more continues. Download day saves the whole day as a text file.

Days and times are Lagos time. If a service writes more than 2 GB of compressed output in a day, history stops keeping its lines until midnight and a note in the history says so. On other plans the live view is the only view, and the History switch explains how to turn it on.

Managed PostgreSQL and Redis are one click away and run as services inside the same project, wired and ready for the apps beside them. A database service has its own tabs: Overview, Data, Deployments, Logs, Security and Settings.

The Data tab lets you look at what is inside without leaving the page, and Security holds the access side. Because the database lives next to the app that uses it, connection details stay inside the project rather than travelling through chat messages.

Every service gets a working URL on deploy, and the Domains tab is where you replace it with your own. Point a domain you own at the service and Dbrij issues and renews the certificate for you; a short "securing your link" wait while the certificate is issued is the only step between pointing the domain and serving on it.

Domains you manage on Dbrij live on the Domains page in the rail. Pointing a domain at an app leaves any mail DNS you have set up untouched, so the same domain can serve the site and receive email at once.

Dbrij Storage is S3 compatible. You get an endpoint, an access key id and a secret, and every tool that speaks S3 works unchanged: command line clients, the S3 SDKs, sync and backup tools, and the storage drivers built into Laravel, Django, Rails and Next.js. Create a bucket under Storage, make a key under Access keys, and copy the endpoint shown there. Both S3 address forms work: the bucket in the path (s3.dbrij.com/bucket/key, path style) or as a subdomain (bucket.s3.dbrij.com/key, virtual host style). The snippets below use path style.

DBRIJ_KEY_ID=dbsk_...
DBRIJ_KEY_SECRET=dbss_...
DBRIJ_S3_ENDPOINT=https://s3.dbrij.com
DBRIJ_S3_REGION=us-east-1
DBRIJ_BUCKET=photos

aws configure set aws_access_key_id dbsk_...
aws configure set aws_secret_access_key dbss_...
aws configure set region us-east-1
aws s3 mb s3://photos --endpoint-url https://s3.dbrij.com
aws s3 cp ./photo.jpg s3://photos/2026/photo.jpg --endpoint-url https://s3.dbrij.com
aws s3 sync ./public s3://photos/site --endpoint-url https://s3.dbrij.com

[dbrij]
type = s3
provider = Other
access_key_id = dbsk_...
secret_access_key = dbss_...
endpoint = https://s3.dbrij.com
region = us-east-1
force_path_style = true

rclone copy ./backups dbrij:photos/backups

'dbrij' => [
    'driver' => 's3',
    'key' => env('DBRIJ_KEY_ID'),
    'secret' => env('DBRIJ_KEY_SECRET'),
    'region' => env('DBRIJ_S3_REGION', 'us-east-1'),
    'bucket' => env('DBRIJ_BUCKET'),
    'endpoint' => env('DBRIJ_S3_ENDPOINT'),
    'use_path_style_endpoint' => true,
],

Storage::disk('dbrij')->put('2026/photo.jpg', $bytes);

import os

AWS_ACCESS_KEY_ID = os.environ["DBRIJ_KEY_ID"]
AWS_SECRET_ACCESS_KEY = os.environ["DBRIJ_KEY_SECRET"]
AWS_STORAGE_BUCKET_NAME = os.environ["DBRIJ_BUCKET"]
AWS_S3_ENDPOINT_URL = os.environ["DBRIJ_S3_ENDPOINT"]
AWS_S3_REGION_NAME = os.environ.get("DBRIJ_S3_REGION", "us-east-1")
AWS_S3_ADDRESSING_STYLE = "path"
STORAGES = {
    "default": {"BACKEND": "storages.backends.s3.S3Storage"},
    "staticfiles": {"BACKEND": "django.contrib.staticfiles.storage.StaticFilesStorage"},
}

import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';

const s3 = new S3Client({
  endpoint: process.env.DBRIJ_S3_ENDPOINT,
  region: process.env.DBRIJ_S3_REGION,
  forcePathStyle: true,
  credentials: { accessKeyId: process.env.DBRIJ_KEY_ID!, secretAccessKey: process.env.DBRIJ_KEY_SECRET! },
});
await s3.send(new PutObjectCommand({ Bucket: process.env.DBRIJ_BUCKET, Key: '2026/photo.jpg', Body: bytes }));

dbrij:
  service: S3
  access_key_id: <%= ENV["DBRIJ_KEY_ID"] %>
  secret_access_key: <%= ENV["DBRIJ_KEY_SECRET"] %>
  endpoint: <%= ENV["DBRIJ_S3_ENDPOINT"] %>
  region: <%= ENV.fetch("DBRIJ_S3_REGION", "us-east-1") %>
  bucket: <%= ENV["DBRIJ_BUCKET"] %>
  force_path_style: true

Prefer plain HTTP over an S3 client? The same key works on the REST storage API with a bearer header, and uploads go straight to the store on a signed URL the API hands you.

Authorization: Bearer <accessKeyId>:<secret>

Base: https://api.dbrij.com/api/storage

GET    /api/storage/buckets                              your buckets
POST   /api/storage/buckets                              { "name": "photos" }
GET    /api/storage/buckets/:bucketId/objects?prefix=    list objects
POST   /api/storage/buckets/:bucketId/upload-url         { "key": "2026/photo.jpg", "contentType": "image/jpeg" }
       → { url, method: "PUT", headers }  then PUT the bytes to url with those headers
POST   /api/storage/buckets/:bucketId/confirm            { "key": "2026/photo.jpg" }  records the real size
GET    /api/storage/buckets/:bucketId/object?key=        302 to a short lived download URL
DELETE /api/storage/buckets/:bucketId/object?key=        delete

• Supported: creating, listing and deleting buckets, uploading and downloading objects of any size (multipart included), ranged downloads, deleting many objects at once, presigned URLs, and copying an object inside the store without downloading it.
• Versioning: turn it on per bucket (PutBucketVersioning, or aws s3api put-bucket-versioning). From then on every overwrite or delete, from the dashboard, the REST API, presets, imports or S3, keeps the previous bytes as a version you can list, fetch by versionId or bring back over S3 by deleting the delete marker. There is no restore button yet. Versions are stored bytes and count toward your storage.
• Bucket policies and ACLs: a policy that grants everyone s3:GetObject on the whole bucket makes it public, the same switch as the dashboard, and a grant on a prefix (arn:aws:s3:::bucket/public/*) makes just that prefix public. An empty policy or a private ACL makes it private. Grants to named principals or with conditions are refused with the reason rather than accepted and not enforced. Give other people their own access keys instead.
• Lifecycle rules: expire objects under a prefix after N days, remove previous versions after N days, and clear delete markers that hide nothing, with the usualaws s3api put-bucket-lifecycle-configuration. Dbrij runs the sweep every hour. Storage class transitions and tag filters are refused, since there is one class and no tags.
• Keys made before S3 support show a REST only tag on the keys page and work on the REST API but not with S3 tools. Make a new key for those.
• Any region name works. The region is part of the signature, not a location; pick one and keep it consistent in your config.
• Billing is per GB stored per month past your plan's allowance, plus per GB served past the monthly transfer allowance on paid plans. Free never bills: uploads stop at its storage cap and serving stops at its transfer allowance until next month.

Every web service carries an Insights tab, so "how is it doing" lives next to the thing that is doing it. It answers three questions:

• Availability: whether the service is up and staying up.
• Performance: how it is responding.
• Audience: who is visiting, from a lightweight analytics beacon. Visitors are counted per day and never tracked across days. The tab includes the installation step for the beacon.

Services that serve HTML also get an SEO tab. For deeper behaviour, replays and funnels, Glass can watch any site you host with one tap, no snippet to paste.

Services in one project reach each other by their names inside the cluster; nothing outside the project can. On the project page, Private network adds mTLS between them, from an authority the project keeps in Secrets Key management.

• Certificates: every service gets a certificate for its names, in /etc/dbrij/mtls, renewed on its own. Use it in your code to call other services and to check who is calling.
• Required: web services also listen on port 8443 for mTLS, and other services in the project can reach them only there. Your app hears the caller's name from its certificate. Try Certificates first, then move your calls to port 8443 before you require it.
• Databases keep their passwords and are reached as before.

• Hosting bills through its own plans, on the Billing page, not through the flat product subscription. You start free and upgrade when you need more.
• Plans are metered. Each plan includes an allowance of compute for the period, sets limits like projects, services per project, replicas, memory and CPU per service, and paid plans meter overage beyond the included allowance. The Usage page shows the current period's meters, so "why is it this much" is answered before the bill arrives.
• Company projects bill the company. A company space carries its own hosting plan, card and usage, separate from any member's personal plan.
• Every deploy gets a live URL with automatic HTTPS, custom domains and managed databases are included on plans that carry them, and push to deploy works from GitHub and from Dbrij Source.
• Email from your app goes through Dbrij Send. Use Dbrij Send's API to send from your own verified domain, with every message tracked.
• Access is granted per person on the Access page; the owner always has it.