Connecting to Databases

MariaDB and PostgreSQL — how credentials reach your app

How it works

Clouderized databases run as separate containers on a private internal network — your app container can reach the database by hostname, but nothing outside your account can. Credentials are never stored in your repo. Instead, they are set as Gitea repo secrets and injected into your container as environment variables at deploy time.

1

Operator sets up the DB

A MariaDB or PostgreSQL container is created on your private network with a dedicated database and user.

2

You add credentials in the portal

Go to your app → Env tab. Add DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASS as individual rows and click Save Changes.

3

Deploy writes app.env

The deploy workflow writes those secrets to app.env before starting the container. Your app reads them from the environment.

Environment variables

These five variables are available in your app at runtime. The operator will give you the values for DB_HOST, DB_PORT, DB_NAME, and DB_USER. You choose DB_PASS.

Variable Example value Description
DB_HOST acme-backend-db Hostname of the database container on your private network
DB_PORT 3306 (MariaDB) · 5432 (PostgreSQL) Database port — standard per engine
DB_NAME acme_db Name of the database created for your app
DB_USER acme_user Database user — has full access to your DB only
DB_PASS •••••••• Password — you set this, the operator applies it to the DB user

Adding credentials in the portal

Go to your app in the portalEnv tab. Add each credential as a separate row — one variable per line, values masked by default. Click Save Changes to write them to app.env and sync the Gitea secret in one step. Then redeploy for the changes to take effect.

The operator will give you the values for DB_HOST, DB_PORT, DB_NAME, and DB_USER when your database is provisioned. You choose DB_PASS.
Never paste DB credentials into your source code or clouderized.yaml. Env vars are encrypted at rest and only exposed to your container at runtime.

Code examples

Python · SQLAlchemy (MariaDB)
import os
from sqlalchemy import create_engine

host = os.environ["DB_HOST"]
port = os.environ["DB_PORT"]
name = os.environ["DB_NAME"]
user = os.environ["DB_USER"]
password = os.environ["DB_PASS"]

engine = create_engine(
    f"mysql+pymysql://{user}:{password}@{host}:{port}/{name}"
)
Python · psycopg2 (PostgreSQL)
import os
import psycopg2

conn = psycopg2.connect(
    host=os.environ["DB_HOST"],
    port=os.environ["DB_PORT"],
    dbname=os.environ["DB_NAME"],
    user=os.environ["DB_USER"],
    password=os.environ["DB_PASS"],
)

Local development

Your app reads the same env vars locally. Create a .env file (git-ignored) for local dev:

.env (local only — never commit)
DB_HOST=localhost
DB_PORT=3306
DB_NAME=myapp_dev
DB_USER=root
DB_PASS=devpassword

On Clouderized, DB_HOST will be the container hostname on your private network — not localhost. Your app doesn't need to change; only the env var values differ between environments.

Resource planning

Databases run inside your resource pool — they consume the same CPU and RAM as your app containers. Plan your slot capacity to cover both workloads.

Database Minimum Recommended
MariaDB / MySQL 0.25 vCPU · 384 MB 0.5 vCPU · 512 MB
PostgreSQL 0.25 vCPU · 512 MB 0.5 vCPU · 768 MB
Redis 0.1 vCPU · 128 MB 0.25 vCPU · 256 MB
PostgreSQL + app on 1 Starter: PostgreSQL at recommended allocation uses ~768 MB — more than a single Starter slot's 512 MB RAM. For app + PostgreSQL together, use 2 × Starter (1 GB RAM combined) or Pro (2 GB RAM). PostgreSQL alone on 1 Starter works at minimum allocation, but leaves little headroom.

Database set up and connected?

Learn how to query your database from the portal, enable remote access, and rotate passwords.

Managing Databases →