Self-Hosting Supabase with Dokploy: Complete Setup on HA Infrastructure

Supabase's managed platform is an excellent way to start building. But as your application scales, the constraints become tangible: row limits on the free tier, compute caps on the Pro tier, and the inability to tune PostgreSQL configuration for your specific workload. Self-hosting Supabase removes those constraints entirely -- you get the full Supabase stack with no artificial limits, running on infrastructure you control.

Dokploy makes self-hosting Supabase practical by providing Docker Compose template support, built-in reverse proxy with automatic SSL, and database backup functionality. This guide walks through deploying a production-grade self-hosted Supabase instance on MassiveGRID infrastructure.

Why Self-Host Supabase

There are four concrete reasons to self-host rather than use the managed platform:

• Data sovereignty: Your data lives on servers you control, in the jurisdiction you choose. For applications handling healthcare data (HIPAA), financial records, or European user data (GDPR), this is often a compliance requirement rather than a preference.
• Cost control: Supabase Pro costs $25/month and includes 8GB database space, 250MB file storage, and 50GB bandwidth. Going past those limits costs extra. A self-hosted instance on a MassiveGRID VPS has no row limits, no bandwidth metering against Supabase, and database storage limited only by your disk allocation.
• Full PostgreSQL access: The managed platform restricts superuser access and limits which extensions you can install. Self-hosted gives you full postgres superuser access -- install any extension, tune postgresql.conf parameters, create custom roles, and run pg_dump directly.
• No vendor lock-in: Your Supabase stack is a set of open-source Docker containers. You can migrate between servers, change hosting providers, or fork the configuration at any time.

What Dokploy Deploys

A self-hosted Supabase installation is not a single container -- it is an orchestrated set of services that communicate through internal networking. Understanding the components helps with sizing, troubleshooting, and scaling decisions.

• PostgreSQL -- The core database. All your application data, auth tables, and Realtime subscriptions live here. This is the most resource-intensive component and the one most sensitive to RAM availability.
• GoTrue -- The authentication server. Handles user signups, logins, OAuth flows, magic links, and JWT issuance. Lightweight in terms of resources but critical for availability.
• PostgREST -- Auto-generates a RESTful API directly from your PostgreSQL schema. When your frontend calls supabase.from('table').select(), PostgREST handles that query translation.
• Realtime -- A WebSocket server built on Elixir that listens to PostgreSQL's replication stream and pushes changes to connected clients. Used for live subscriptions and presence.
• Kong -- The API gateway that sits in front of all other services. Routes requests to the correct backend service, handles rate limiting, and manages API keys.
• Supabase Studio -- The web-based admin UI. Provides a table editor, SQL editor, authentication management, and storage browser. This is the interface you interact with to manage your Supabase instance.
• Storage API -- Handles file uploads and serves stored files. Backed by the local filesystem or S3-compatible storage.
• Meta -- A service that exposes PostgreSQL metadata for the Studio UI to display schema information.

These services communicate over Docker's internal network. Kong is the only service that needs to be publicly accessible (along with Studio for admin access). Dokploy's Traefik reverse proxy handles external routing and SSL termination.

Infrastructure Sizing

Supabase is the strongest case for independent resource scaling on MassiveGRID. Here is why: the components collectively need 4GB+ RAM in production, but they are not CPU-intensive during normal operation. PostgreSQL wants RAM for its shared buffers and working memory. GoTrue, PostgREST, and Kong are lightweight. Realtime needs memory proportional to concurrent WebSocket connections.

This means the bottleneck is almost always RAM, not CPU. On infrastructure where you can scale RAM independently from CPU, you pay for what you actually need instead of upgrading to a higher tier that bundles CPU cores you will not use.

The key takeaway: start with enough RAM for the full stack (4GB minimum), and scale RAM first as your database grows. CPU scaling becomes important only when you have high concurrent query loads or heavy PostgREST usage.

Step-by-Step Deployment

Before starting, ensure you have Dokploy installed on your server. The installation takes under 15 minutes.

1. Create a Docker Compose Service

Log into Dokploy's dashboard. Create a new project (e.g., "Supabase"). Inside the project, click Create Service and select Compose.

Dokploy supports deploying Docker Compose stacks directly. You can paste a docker-compose.yml or point to a Git repository containing one. For Supabase, use the official self-hosting repository:

1. Set the source to GitHub and point to the supabase/supabase repository, or use the Raw option to paste the docker-compose.yml from Supabase's self-hosting documentation.
2. Supabase provides a docker-compose.yml and a .env.example file. You will need to configure the environment variables before deploying.

2. Configure Environment Variables

The Supabase stack requires several environment variables to be set correctly. In Dokploy's environment tab for the Compose service, add the following (generating secure values for secrets):

POSTGRES_PASSWORD=your-secure-database-password
JWT_SECRET=your-jwt-secret-at-least-32-characters
ANON_KEY=your-generated-anon-key
SERVICE_ROLE_KEY=your-generated-service-role-key
DASHBOARD_USERNAME=admin
DASHBOARD_PASSWORD=your-studio-password
SITE_URL=https://your-app-domain.com
API_EXTERNAL_URL=https://api.your-domain.com
SUPABASE_PUBLIC_URL=https://api.your-domain.com

The ANON_KEY and SERVICE_ROLE_KEY are JWTs signed with your JWT_SECRET. Supabase provides a JWT generator in their documentation, or you can generate them with any JWT library using the HS256 algorithm. The anon key should have the role anon, and the service role key should have the role service_role.

3. Deploy the Stack

Click Deploy in Dokploy. It will pull all container images, create the internal Docker network, and start the services in the correct order. The initial pull takes a few minutes depending on your server's bandwidth. Subsequent deployments are faster because Docker caches the layers.

Monitor the deployment logs in Dokploy's log viewer. You should see PostgreSQL initialize first, followed by the other services connecting to it. Once all services report healthy status, your Supabase instance is running.

4. Configure Domain and SSL

In Dokploy, add a domain for the Kong API gateway service (the main entry point). Traefik will automatically provision a Let's Encrypt SSL certificate. Point your DNS A record to your server's IP address.

For Studio access, you can either configure a separate subdomain (e.g., studio.your-domain.com) or access it through the Kong gateway at the /studio path, depending on your Supabase configuration.

Configuration

SMTP for Authentication Emails

GoTrue sends transactional emails for signups, password resets, and magic links. Without SMTP configuration, these features will not work. Add your SMTP credentials to the environment variables:

SMTP_HOST=smtp.your-provider.com
SMTP_PORT=587
SMTP_USER=your-smtp-username
SMTP_PASS=your-smtp-password
SMTP_SENDER_NAME=Your App
SMTP_ADMIN_EMAIL=admin@your-domain.com

Services like Resend, Postmark, or Amazon SES work well. Avoid using Gmail SMTP for production -- it has sending limits that will cause issues as your user base grows.

Storage Configuration

Supabase Storage uses the local filesystem by default. For production, ensure the storage volume is mapped to a persistent Docker volume so files survive container restarts. The default Compose file handles this, but verify the volume mount in the storage service configuration.

If you need S3-compatible storage for larger file volumes, configure the STORAGE_BACKEND environment variable to point to your S3 bucket (or any S3-compatible provider like MinIO).

Backup Strategy

Your Supabase data lives in PostgreSQL, so database backups are the critical piece. Dokploy provides built-in database backup functionality that you should configure immediately after deployment.

Automated PostgreSQL Backups

Dokploy can run pg_dump on a schedule and store the backups locally or upload them to S3-compatible storage. Configure this in the database service settings:

• Frequency: Daily for most applications. Hourly if you have high write volumes or cannot tolerate more than an hour of data loss.
• Retention: Keep at least 7 daily backups and 4 weekly backups. Storage is cheap; losing data is not.
• Off-server storage: Always store at least one copy of backups off-server. Configure S3 upload or rsync to a remote location.

Testing Restores

A backup you have never tested is not a backup. Periodically restore a backup to a test database to verify integrity. You can spin up a temporary PostgreSQL container in Dokploy, restore the dump, and verify that your application can read the data correctly.

Growth Path

Supabase usage patterns follow a predictable trajectory. Understanding this helps you plan scaling decisions in advance rather than reacting to outages.

Phase 1: Development to Launch

A 4GB RAM VPS handles everything. Your dataset is small, concurrent users are few, and you are focused on building features. Dokploy and Supabase share the server comfortably.

Phase 2: Growing User Base

As your database grows past a few gigabytes and concurrent connections increase, PostgreSQL wants more RAM for shared buffers and connection handling. This is where independent scaling is most valuable -- scale RAM from 4GB to 8GB or 16GB without changing your CPU allocation. On MassiveGRID, this is a configuration change, not a server migration.

Phase 3: Production SaaS

When Supabase is the data layer for a product with paying customers, availability becomes non-negotiable. Move to Cloud Dedicated servers for high availability with automatic failover. The managed operations mean MassiveGRID handles server-level maintenance, security patching, and monitoring while you focus on your application.

At this stage, you might also consider separating PostgreSQL onto its own dedicated server for maximum performance, with the Supabase application services (GoTrue, PostgREST, Realtime, Kong) on a separate server. Dokploy supports multi-server deployments for this kind of architecture.

Next Steps

With Supabase running on your own infrastructure through Dokploy, you have a fully-featured backend-as-a-service with no row limits, full PostgreSQL access, and predictable costs. From here:

• Install Dokploy if you have not set up the platform yet
• Read the VPS sizing guide for detailed resource recommendations
• Secure your Dokploy instance with firewall rules, SSH hardening, and access controls
• Understand shared vs. dedicated resources to choose the right tier for your Supabase workload

Self-hosting Supabase is not about avoiding paying for software. The managed platform is a fair product at a fair price for many use cases. Self-hosting is about control -- control over your data location, your PostgreSQL configuration, your scaling trajectory, and your costs. Dokploy and MassiveGRID make that control accessible without requiring deep infrastructure expertise.