DEV Community: Thomas Plat

Deploying a Complex Cursor-Built App: Prisma, Postgres, Inngest & Supabase on Vercel, Railway and Jetpacked

Thomas Plat — Sun, 07 Jun 2026 11:09:42 +0000

I built a complex full-stack application with Cursor to see how different deployment platforms handle realistic AI-generated code.

Not a todo app. Not a landing page. Not a clean demo with one framework and one environment variable. I wanted something closer to what people actually end up building when they spend a few evenings with Cursor, Claude, ChatGPT, or any of the newer agentic coding tools: a product-shaped app with auth, a database, background work, third-party APIs, and enough moving parts that deployment stops being a simple npm run build.

The result was VibeSplit, a group expense splitter with AI receipt scanning.

The Test App

VibeSplit lets a group upload receipts, parse them with AI, split expenses, track balances, invite other people, and settle up. It is intentionally the kind of app that feels easy to create with an AI coding assistant and then suddenly becomes much harder when it has to run somewhere real.

The stack looked like this:

Next.js 15 with the App Router and TypeScript
Prisma with PostgreSQL
Supabase Auth for magic links and Google login
Inngest for background jobs
OpenAI Vision for receipt parsing
Stripe for settlement payments
Resend for application emails

This is exactly the shape of many vibe-coded apps I see: the code works locally, but production needs a real database, real secrets, OAuth redirect URLs, webhook URLs, background jobs, migrations, and build-time public environment variables.

That last phrase matters more than it sounds. Some variables are runtime-only. Others, like NEXT_PUBLIC_SUPABASE_URL, are baked into the browser bundle during the Next.js build. If a platform passes environment variables only when the container starts, the backend may be fine while the frontend quietly ships with placeholder values.

Why This Was A Useful Test

Simple apps hide deployment problems. A static frontend can make almost any platform look good. A basic Next.js app with no database and no integrations usually deploys without much drama.

VibeSplit surfaced the messier parts:

Prisma needs a valid DATABASE_URL and production migrations.
Supabase Auth needs public client values at build time and redirect URLs after deploy.
Stripe needs callback URLs that point to the live app.
Inngest needs a reachable endpoint for background jobs.
OpenAI and Resend need server-side secrets.
The app needs to bind to the correct port inside a container.

The goal was not to prove that any platform is bad. The goal was to see which platform understood the shape of the app without making me manually reconstruct the architecture in a dashboard.

Railway

Railway handled the Next.js part reasonably well at first. It detected that the app was a Node/Next project and tried to run it in the expected way.

The first problem was the port. The initial deployment came up with a 502 error because the app and the platform did not agree on the port. This was resolved fairly quickly, but it is exactly the kind of issue that breaks the illusion of one-click deploy. The app was alive somewhere, but traffic was not reaching it correctly.

After the port issue, the bigger problem was the database. Railway did not provision a PostgreSQL database automatically for this repo. The app used Prisma, had a Prisma schema, and clearly needed a database, but I still had to add Postgres manually.

That meant I had to wire DATABASE_URL, think about Prisma migrations, and check whether the runtime environment matched what the app expected. Even after adding Postgres, I still ran into internal server errors. At that point the deployment had moved from "deploy my repo" to "debug platform configuration, application assumptions, and service wiring at the same time."

Railway is powerful once you know what you are doing, but for this kind of AI-generated full-stack app, it still expected too much manual reconstruction.

Vercel

Vercel deployed the frontend successfully. That is not surprising; Vercel is very good at Next.js.

But the live site returned a 500 Internal Server Error. The frontend build existing was not enough. This app was not just a frontend. It needed a database, Prisma, migrations, Supabase values, API routes, server actions, and several third-party secrets.

The tricky part with Vercel is that a successful deployment can look deceptively complete. The build passes, a URL exists, and the app is technically online. But the first real user flow reveals what was missing.

In this case, the platform did not infer the full backend shape of the application. I still had to think through the database and environment setup myself. For a clean Next.js app, that is fine. For a multi-service vibe-coded app, the gap is noticeable.

Jetpacked

Jetpacked detected the app as a full-stack deployment instead of treating it as just a Next.js frontend.

It picked up the Postgres requirement, the Prisma setup, and the required environment variables. That made the deployment feel closer to the way I want this category of platform to work: read the repo, understand the stack, then ask me for the values that cannot be inferred.

The deployment completed with the least friction of the three. I did not have to manually create a database first and then wire the app around it. The platform understood that the database was part of the application shape.

That said, it was not magic. A few things still required manual attention.

Supabase Auth redirect URLs had to be configured in the Supabase dashboard after deployment. This is easy to forget. The app can deploy perfectly and still fail login if Supabase only allows localhost:3000 as a redirect target.

I also ran into the difference between runtime and build-time environment variables. For Next.js, public variables like NEXT_PUBLIC_SUPABASE_URL must be available during the build or the frontend bundle can contain placeholder values from .env.example. That is a subtle production issue because the container can have the correct runtime env while the browser is already running code built with the wrong value.

This is the kind of issue that deployment tooling needs to understand. It is not enough to inject env vars into the running container. For frameworks like Next.js, some of them must also be passed into the build.

Supabase Was Its Own Step

Supabase Auth introduced a separate class of deployment work.

The app used Supabase for magic links and Google login. The environment variables pointed the app to the correct Supabase project, but Supabase itself still needed production URL configuration.

The Google provider had to be enabled in Supabase. The deployed callback URL had to be added. The site URL had to stop pointing at localhost. None of that lives in the application repo, and no hosting platform can fully infer it from code.

This is an important lesson for vibe coders: when your app uses external auth, deployment is not only about your server. It is also about configuring the provider to trust the new production URL.

What I Learned

Complex vibe-coded apps need platforms that understand more than framework names.

Detecting "Next.js" is useful, but it is not enough. The real deployment shape is Next.js plus Prisma plus Postgres plus migrations plus Supabase plus background jobs plus public build-time env vars plus server-only secrets.

Railway got me part of the way there but required manual service setup and port debugging. Vercel handled the frontend but did not solve the full-stack requirements by itself. Jetpacked handled the complete setup noticeably smoother for getting the app live quickly.

The rough edges were instructive. Supabase still needs manual provider and redirect configuration. OAuth still depends on external dashboards. Build-time environment variables still matter. But the core deployment path was much closer to what I want: connect the repo, detect the real stack, provision what the app needs, and surface the remaining configuration clearly.

That is the bar deployment platforms need to clear for AI-generated applications. Not "can it build a Next.js app?" but "can it understand the messy, service-heavy thing someone actually built?"

The Container Port Binding Mistake That Breaks Almost Every First Deploy

Thomas Plat — Wed, 03 Jun 2026 06:40:17 +0000

You deploy your app. The build succeeds. The logs show the server starting. You click the URL your deployment platform gave you and get a connection error, a 502, or nothing at all.

This is one of the most common first deployment failures, and the cause is almost always the same: the app is binding to the wrong address, or listening on the wrong port, or both.

What port binding actually means

When a server app starts, it listens for incoming connections on a network address. That address has two parts: the IP address it listens on, and the port number.

The IP address determines which network interfaces the application accepts connections from. localhost (which resolves to 127.0.0.1) means the app only accepts connections from the same machine. 0.0.0.0 means the app accepts connections from any network interface, including external ones.

During local development, localhost is fine. Everything is on the same machine. Your browser and your server are both on your laptop. When you deploy to a server, the platform's load balancer is not on the same machine as your app. It is trying to connect from outside. An app bound to localhost is invisible to it.

The port problem

Deployment platforms often assign ports dynamically. They tell your app which port to use through an environment variable, almost always called PORT. Your app needs to read this variable and bind to that port.

If your app ignores PORT and hardcodes a port number, it starts on a port the platform is not watching. The platform tries to connect on its assigned port, gets nothing, and marks the deployment as failed.

// This will fail on most platforms
app.listen(3000)

// This is correct
app.listen(process.env.PORT || 3000)

The || 3000 fallback makes the app work both locally (where PORT is not set) and in production (where the platform sets it).

What AI tools generate

AI tools often hardcode both the address and the port. The generated code looks like this:

app.listen(3000, 'localhost', () => {
  console.log('Server running on http://localhost:3000')
})

This is correct for local development and wrong for production. The 'localhost' argument is the binding address. Remove it entirely or replace it with '0.0.0.0'. Replace 3000 with process.env.PORT.

The same pattern appears across multiple frameworks. Express does it. Fastify does it. Hapi does it. The underlying behavior is the same in all of them.

Framework-specific fixes

Express:

const port = process.env.PORT || 3000
app.listen(port, '0.0.0.0')

Fastify:

await fastify.listen({ port: process.env.PORT || 3000, host: '0.0.0.0' })

AdonisJS: Set HOST=0.0.0.0 and PORT in your environment. AdonisJS reads both from environment variables automatically.

Next.js: Next.js handles port binding correctly by default and reads PORT from the environment. No manual fix needed.

NestJS:

await app.listen(process.env.PORT || 3000, '0.0.0.0')

How to diagnose it

If your deployment shows the application is starting but the health check is failing, check two things in the startup logs:

First, what address is the server logging? If you see Listening on http://localhost:3000 or Server running on 127.0.0.1:3000, the app is bound to localhost. External traffic cannot reach it.

Second, what port is the app using? If it is hardcoded and does not match the PORT environment variable, the platform is sending traffic to the wrong port.

Both of these are visible in the startup log lines that most frameworks print when they start successfully.

Why this is so consistent

This failure is nearly universal for first deployments because it is invisible during development. The hardcoded localhost binding works perfectly when you are testing locally. Nothing ever fails. The code ships, the app starts on the server, and the binding address becomes a problem for the first time.

Catching this before deployment is one of the more valuable things a deployment platform can do automatically. jetpacked.ai detects hardcoded port and address bindings during repo analysis — apps that don't listen on 0.0.0.0 or ignore PORT won't serve traffic, and surfacing that before the build starts saves the debugging loop entirely.