Deploy and Host self hosted Supabase Cron (Scheduled Jobs Inside Postgres) on Railway

This template runs self-hosted Supabase on Railway with pg_cron for scheduling jobs inside Postgres.

About Hosting Supabase Cron open-source software on Railway (self hosted pg_cron job scheduling for self-hosted Supabase template)

Your scheduled jobs live inside your own Postgres, so every cron.schedule call, row in cron.job, and entry in cron.job_run_details stays in a database you control.

Why Deploy Supabase Cron, the Supabase Cloud alternative on Railway (Railway Free Trial)

Supabase Cloud already ships a Cron dashboard, so self hosting is about control.

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Supabase Cron on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Railway vs Other Hosting Providers and VPS for Supabase Cron self hosting

Self-hosting Supabase Cron means running Postgres plus several supporting services, so your hosting choice sets how much you manage yourself.

Provider	What You Get with Railway	What You Get with the Other Provider
DigitalOcean	All nine services deployed with generated secrets and a ready supabase gateway domain.	A Droplet you size, harden, and patch, with Docker Compose and firewall rules on you.
AWS	Managed services with a volume for the db service, so no VPC or IAM setup just to run pg_cron.	Fine-grained networking and scaling, but you build deployment and monitoring yourself.
Hetzner	A predictable monthly bill without touching the host or SSH.	Low-cost resources with generous bandwidth, and you own the OS, Docker, and Postgres backups.

Choose Railway for a fast start, or a VPS when you want full host control.

Common Use Cases for hosted Supabase Cron

Most teams reach for Supabase Cron once a job feels too fiddly to keep in an app server.

Nightly cleanup of stale rows: Schedule a delete on an events table with select cron.schedule('saturday-cleanup', '30 3 * * 6', $$ delete from events where event_time < now() - interval '1 week' $$);.
Refreshing cached data through an Edge Function: Ping a Supabase Edge Function every five minutes to rebuild a cache table. Enable pg_net, then queue a net.http_post call to the functions route on your supabase service domain.
Pruning cron.job_run_details: Run history is never cleaned up automatically, so a daily job deleting rows older than seven days keeps the table small.
Pausing jobs during maintenance: Call cron.alter_job with active := false before a migration, then set it back to true afterward.
Retrying and inspecting failed HTTP calls: pg_net keeps responses for six hours, so you can query net._http_response for status codes of 400 or higher to see which calls failed.

Dependencies for Supabase Cron Docker hosted on Railway

The cron jobs live inside the db service's Postgres, so that's the piece you care about most.

Deployment Dependencies for Managed Supabase Cron Service (Backend as a Service)

Railway account: a project with room for nine services and volumes for db, storage, and studio.
Generated secrets: JWT_SECRET, POSTGRES_PASSWORD, DASHBOARD_PASSWORD (username supabase), PGSODIUM_ROOT_KEY, and the realtime and meta encryption keys.
Public gateway: the supabase service on port 8000 routes /functions/v1, with Studio behind HTTP basic auth.
Memory: plan for roughly 4 GB RAM across the stack, matching upstream guidance.
Outbound HTTP: pg_net sends calls from inside Postgres, so db must reach the supabase gateway domain.

Implementation Details for Supabase Cron (Using Supabase official docker image)

Enable pg_cron and pg_net in that database, then schedule jobs from Studio's SQL editor.

How does Supabase Cron compare against other ways to schedule recurring jobs on Supabase and Postgres

Supabase Cron vs Supabase Cloud (Integrations Cron dashboard)

Scheduling surface: Cloud gives you the Integrations Cron dashboard, while self-hosted means writing cron.schedule calls in SQL against the db service.
Where jobs live: Cloud keeps cron.job and cron.job_run_details in a managed project, and self-hosted keeps them on your own volume, so you own the history.
Where Cloud wins: Managed backups and the dashboard make Cloud easier if you'd rather not touch the database.

Supabase Cron vs Vercel Cron (scheduled Vercel function invocations)

Trigger model: Vercel Cron invokes functions from your project config, while Supabase Cron runs SQL inside Postgres and reaches Edge Functions over pg_net.
Data access: A stale-row cleanup is one statement with Supabase Cron, but on Vercel it means an HTTP handler and a database client.
Where Vercel wins: If your app already lives on Vercel and the work is application logic, its cron means fewer moving parts.

Supabase Cron vs GitHub Actions schedules (cron workflows on GitHub runners)

Execution location: Actions runs on GitHub-hosted runners and reaches your database over the network, while Supabase Cron runs next to the data.
Run history: Supabase Cron records each run in cron.job_run_details, queryable with plain SQL; Actions keeps logs in the GitHub UI.
Where Actions wins: Build, test and deploy workflows belong in Actions.

Supabase Cron vs Inngest (hosted scheduled functions via TypeScript SDK)

Programming model: Inngest offers retries, fan-out and step functions through a TypeScript SDK, while Supabase Cron gives you one SQL statement per job.
Hosting: Inngest is a hosted platform you call out to, while Supabase Cron keeps the scheduler and history on infrastructure you run.
Where Inngest wins: Multi-step workflows needing durable retries across many services fit Inngest better than a single Postgres scheduler.

How to use Supabase Cron (the OSS Firebase alternative)?

Confirm pg_cron is available in your self-hosted db image first, since the upstream guide does not cover self-host setup. Run select * from pg_available_extensions where name = 'pg_cron'; and if no row comes back, the image lacks the extension. 2. Open the db service's Postgres and schedule with a five-field cron expression:

select cron.schedule('saturday-cleanup', '30 3 * * 6', $$ delete from events where event_time &lt; now() - interval '1 week' $$);

Check recent runs with select * from cron.job_run_details where jobid = (select jobid from cron.job where jobname = '...') order by start_time desc limit 10;
To call an Edge Function, enable pg_net and schedule a net.http_post to the supabase service domain at /functions/v1, with the anon key from the supabase service logs as the apikey header:

select cron.schedule('refresh-cache', '*/5 * * * *', $$ select net.http_post(url := 'https://your-supabase-domain/functions/v1/refresh', headers := jsonb_build_object('Content-Type', 'application/json', 'apikey', 'your-anon-key'), body := '{}'::jsonb) $$);

How to self host Supabase Cron on other VPS Services (Supabase self hosting guide)

These steps follow the upstream Supabase self-hosting docs.

Clone the Repository

Pull the official Supabase repo and move into the Docker directory.

git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker

Install Dependencies

You need Docker and the Compose plugin on the VPS.

docker --version
docker compose version

Configure Environment Variables

Copy the example env file and replace every secret before starting anything.

cp .env.example .env
nano .env

Change POSTGRES_PASSWORD, JWT_SECRET and the dashboard password, then set API_EXTERNAL_URL to https://your-domain.

Start the Supabase Cron Application

Pull the images and bring the stack up in the background.

docker compose pull
docker compose up -d
docker compose ps

Railway handles the reverse proxy, TLS certificates, persistent volumes and restarts for you, so none of these steps are needed there.

Official Pricing of Supabase Cron (Supabase pricing)

Supabase Cron is free and open source under Apache-2.0, so there's no license fee for the scheduling module or the pg_cron extension behind it.

Supabase Cron cloud vs self hosted comparison (Pricing, features, costs, and more)

Supabase Cloud gives you the Integrations Cron dashboard and managed backups.

Monthly cost of self hosting Supabase Cron on Railway

Self-hosting is free, so your cost is Railway usage.

System Requirements for Hosting Supabase Cron on a VPS

Upstream Supabase suggests at least 4 GB of RAM for the full stack.

Frequently Asked Questions (FAQs)

Do I need Supabase Cloud's Integrations Cron dashboard to schedule jobs?

No.

Why does my job overwrite an existing one with the same name?

Job names are the unique key, so calling cron.schedule with an existing name replaces the old schedule and command.

How do I stop cron.job_run_details from growing forever?

pg_cron never trims that table, so schedule a cleanup job.

Are pg_net calls retried automatically?

No. pg_net sends each request once and keeps the outcome in net._http_response for six hours by default.

How many jobs can run at once?

The upstream docs recommend up to 8 concurrent jobs, each finishing within 10 minutes.

Can I schedule sub-minute jobs?

Yes, using a seconds form such as '30 seconds', but only on Postgres 15.1.1.61 or later. Keep the volume attached; it holds all state. Keep the volume attached; it holds all state.