Deploy and Host Complete Supabase + NextJS Frontend on Railway

PG On Rails is a passion project that combines two of my favourite things: Supabase and Railway! It is local-first and is a joy to build Supabase applications with. It is a monorepo with one directory per service, and is designed for the modern deployment pattern of watch paths.

My longterm vision is to make PG On Rails the best strategy for bootstrapping, building and self-hosting Supabase.

About Hosting PG On Rails

Please visit the official GitHub repo to view GIFs of the deployment process.

To deploy this template, only 3 environment variables need to be configured. Please visit the Supabase self-hosting tool to generate a JWT secret and keys, and input them when prompted into the Postgres service.

You can use your deployment as a remote backend only, or you can practice truly local-first development by running your project on your machine. To do this, you'll need to eject the project and clone your newly forked GitHub repo.

Whether remote or local, you'll be able to use the Supabase Studio dashboard right away, by copying the DASHBOARD_PASSWORD variable from the Kong service. Visit the public url for Kong, and log in with user pgonrails and the password.

After you've successfully deployed and ejected your project, you'll need to run database migrations in order to use the NextJS example frontend, "Trello Clone". Follow the instructions in the project README to migrate your DB.

Common Use Cases

• Postgres database with instant APIs
• Auth, Edge Functions, Websockets
• S3-compatible storage, Vector embeddings
• Startups, Scale-ups, SaaS

Dependencies for Complete Supabase + NextJS Frontend Hosting

• Docker Desktop
• Supabase CLI

Deployment Dependencies

In order to deploy this template smoothly, you must create a JWT secret and keys using the Supabase online self-hosting tool. The link to it is provided directly in the environment configuration UI.

Implementation Details

Sane and simple defaults

Get working on real application features in seconds. We go the extra mile to make default configuration minimal while still covering everything needed to run out-of-the-box. Avoid drowning in config, and opt in to more hackability as needed.

Add your app logic, deploy seamlessly

Every service gets its own directory, so watchpaths just work. Add new functions, configuration files, migrations, and anything else to a service's repo, commit your work, and Railway (or your CI/CD of choice) will trigger a new build.

Your frontend, included in the stack

Reduce context-switching and host as much of your stack as possible on the same platform. For NextJS, Django, htmx or any server-rendered frontend, get fast and secure access to Supabase data APIs via the shared internal network.

Full control over your application

For the hackers. Configure every aspect of your Supabase application and version it in code:

• Email templates
• Third-party auth providers
• Environment variables
• Networking settings
• Railway config-as-code

Railway observability instead of Logflare

The entire Supabase feature set for building applications has been extensively tested and proven via the included NextJS app, "Trello Clone". At this time, it doesn't include a Logflare analytics service, and opts to use Railway's platform observability instead.

Frontend included with seamless dev mode

We included a frontend app in the stack and named it site. The frontend site is a NextJS app built with create-next-app, tailwindCSS and shadcn/ui. It includes basic auth functionality so you can begin building user experiences out of the box.

Separate Dockerfiles for development and deployment

The project is setup so that running the Docker Compose stack locally runs the site in dev mode. The local dev experience points to a dev.Dockerfile in the site repo. This dockerfile runs the NextJS dev server. For production, however, Railway looks for a Dockerfile by default (no dev prefix), and will deploy using the Dockerfile which builds and serves the optimized site.

The other strategy which enables smooth local development inside Docker, is mounting the entire site directory as a volume inside the dev container (volumes: - ./site:/app). This exposes the codebase from your local filesystem inside the container, where the dev server can pick up any changes and deliver that hot-reload experience we all love.

No mail server yet, no problem

By default, mailing is disabled. Once a user signs up with their email and password, their email is "auto-confirmed" by the auth server and they are signed in.

Setup mailing fast

The auth server requires an SMTP server to send transactional emails. In my experience, the quickest way to get up and running in both local and non-production cloud environments, is through a gmail account with an app password.

Log in to the Google account you want all transactional emails to come from. Visit the following link to create a Google app password.

Make sure the email signup and SMTP environment variables are set:

GOTRUE_MAILER_AUTOCONFIRM=false [email protected] [email protected] GOTRUE_SMTP_PASS="abcd efgh ijkl mnop" GOTRUE_SMTP_HOST=smtp.gmail.com GOTRUE_SMTP_PORT=587 GOTRUE_SMTP_SENDER_NAME: "PG On Rails"

NOTE - SMTP traffic on Railway is only allowed for the Pro Plan and above.

Why Deploy PG On Rails on Railway?

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 PG On Rails 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.