Install

Install on Render

Outcome: Mailnib running on Render with its own PostgreSQL database and a persistent disk for uploads.

The source/ folder of your download includes render.yaml, a Render Blueprint. It creates three things for you: the web service, a PostgreSQL database, and a 10 GB disk mounted at /var/data for customer uploads.

Before you start

• A Render account on a plan that allows a persistent disk (disks are not available on free web services).
• A Git repository that Render can read, for example a private GitHub repository, holding the contents of the source/ folder. Render builds the app from source, so runtime/ is not used here.

1. Put the source in a repository

On your computer, open a terminal inside the source folder (the one that contains package.json and render.yaml) and run:

git init
git add .
git commit -m "Mailnib"
git branch -M main
git remote add origin https://github.com/YOUR-NAME/mailnib.git
git push -u origin main

Create the empty private repository on GitHub first and use its address. The .gitignore in source/ keeps secrets and build folders out.

2. Create the Blueprint

1. In the Render dashboard, click New and choose Blueprint.
2. Connect the repository that holds Mailnib and select it.
3. Render reads render.yaml and lists the service mailnib and the database mailnib-db. Click Apply (or Create).

3. Fill in the variables Render asks for

Render prompts for every variable the Blueprint marks as yours to fill. Set at least:

The SMTP_* and MAIL_* variables can be filled now or later; see Email (SMTP) settings. DATABASE_URL, MIGRATE_ON_START and STORAGE_ROOT are already set by the Blueprint.

4. Wait for the first deploy

The first deploy installs dependencies and builds the app, which takes several minutes. When the service shows Live, open https://your-address/api/health. You should see:

{"ok":true,"db":"connected","migrations":"up to date"}

5. Run the installer

1. Open the mailnib service and click Logs.
2. Find the lines that start with Mailnib is not installed yet. The long code under them is your setup token. Copy it.
3. Visit https://your-address/install and paste the token.
4. Follow The web installer.

Failed-payment reminders

If you take card payments, add a Render Cron Job that calls the reminder endpoint, as described in Payment providers, and set CRON_SECRET on the web service.

Where your data lives

• The database is the Render PostgreSQL instance. Turn on backups for it in Render.
• Uploads are on the /var/data disk.

PostgreSQL role privileges

Use a dedicated login role that owns this application's tables and functions. It needs CONNECT and CREATE on the database, USAGE and CREATE on the application schema (public), and permission to create the drizzle migration schema. Migrations need to create and alter tables, indexes, policies, triggers and functions; normal operation reads and writes those tables and executes the shipped functions. Use the same role for the installer, migrations and DATABASE_URL.

NOSUPERUSER NOBYPASSRLS is supported and recommended. Neither superuser nor BYPASSRLS nor permission to create roles is required. Tenant tables retain FORCE ROW LEVEL SECURITY even for their owner. Verified webhooks, the authenticated operator console and the secret-authenticated dunning scheduler discover workspaces through fixed, read-only functions, then enter a workspace scope for tenant data and writes. Never share the application's database credentials with tenants or browser code. Test setup creates roles to verify isolation; those privileges are needed only by the test administrator.

On managed PostgreSQL, use the database/schema owner supplied by the provider, or have the provider grant the schema creation privileges above. On cPanel, ask the host to grant these privileges if the control-panel database user cannot create schemas or functions. No elevated RLS-bypass role is needed.