Moving from a frontend cloud to Open Source Cloud
Frontend clouds made deploying a Next.js app a one-click job. The trade is that the app ends up tied to one vendor for its runtime, its storage and its bill. This page is for teams who want the same app running on open source services instead. If you are on Vercel, this is the path we would take.
What maps where
For a Next.js or other Node.js app deployed from a git repository. Every service on the right is open source and runs in your own workspace.
On a frontend cloud: Git-connected Next.js or Node.js deploy
On Open Source Cloud: My Apps
Point it at GitHub or any HTTPS git host. Append #branch to deploy a branch other than the default. Private repositories use a registered git credential.
On a frontend cloud: Environment variables and secrets
On Open Source Cloud: Parameter store
Values reach your app as environment variables, and secret values are decrypted on the way in.
On a frontend cloud: Postgres from a marketplace provider
On Open Source Cloud: PostgreSQL
Move the data with pg_dump and pg_restore. Postgres Vector is there if you store embeddings.
On a frontend cloud: Redis-style key-value store
On Open Source Cloud: Valkey
Redis-compatible, so a Redis client should only need a new connection string. We have not yet tested Valkey from a My App, so check it on a copy first.
On a frontend cloud: Blob storage
On Open Source Cloud: MinIO
S3-compatible. Any S3 client, including the AWS SDK, works with a custom endpoint.
On a frontend cloud: Web analytics
On Open Source Cloud: Umami or Plausible
Both open source and both in the catalog.
| On a frontend cloud | On Open Source Cloud | Notes |
|---|---|---|
| Git-connected Next.js or Node.js deploy | My Apps | Point it at GitHub or any HTTPS git host. Append #branch to deploy a branch other than the default. Private repositories use a registered git credential. |
| Environment variables and secrets | Parameter store | Values reach your app as environment variables, and secret values are decrypted on the way in. |
| Postgres from a marketplace provider | PostgreSQL | Move the data with pg_dump and pg_restore. Postgres Vector is there if you store embeddings. |
| Redis-style key-value store | Valkey | Redis-compatible, so a Redis client should only need a new connection string. We have not yet tested Valkey from a My App, so check it on a copy first. |
| Blob storage | MinIO | S3-compatible. Any S3 client, including the AWS SDK, works with a custom endpoint. |
| Web analytics | Umami or Plausible | Both open source and both in the catalog. |
What does not move over as it is
Better to know this before you start than halfway through.
- Edge runtime code. Your app runs as a standard Node.js server here. Functions or middleware written for an edge runtime need to run on Node.js first.
- Vendor storage SDKs. Code that imports a vendor package for its database, key-value store or blobs needs the standard client instead: pg, a Redis client, an S3 client.
- A preview deployment for every pull request. We have not verified an automatic equivalent. You can run a branch as its own app by adding #branch to the repository URL.
If most of your app is edge functions, the move is a rewrite, not a migration. If it is a normal Next.js server with a database, it is mostly configuration.
What we tested on a stock Next.js app
On 14 October 2026 we ran a stock create-next-app project (Next.js 16.4, App Router, TypeScript, Tailwind) on My Apps without changing its code. No Dockerfile, no config file, no port setting.
- npm install ran with devDependencies, so TypeScript and Tailwind were there at build time.
- next build and next start ran as written in package.json.
- The app listened on port 8080, picked up from the PORT variable the platform sets. No code change needed.
- A route rendered on the server returned a new timestamp on every request, so server rendering works, not only static pages.
- A rebuild after a new commit was live within a couple of minutes.
What that test did not cover: the data move, Valkey, a GitHub source (we used a git repository hosted on Open Source Cloud), Next.js versions before 16, middleware, image optimisation, route handlers under /api, incremental static regeneration, NEXT_PUBLIC_ variables at build time and custom domains. Try them on a copy of your app before you move traffic.
The steps as a machine-readable recipe for your AI agentThe move, step by step
Create the data services
Start PostgreSQL, Valkey and MinIO from the catalog, or ask your AI agent to do it over MCP.
Move the data
pg_dump from the old database and pg_restore into the new one. Copy blobs with any S3 client pointed at the MinIO endpoint.
Set the environment variables
Put the new connection strings and your other variables in a parameter store.
Create the app
Create a My App from your repository and point it at the parameter store. It builds with next build and starts with next start.
Check it
Open the app on its Open Source Cloud address and click through the paths your users depend on.
Switch over
Point your domain at the new app. Keep the old deployment running until the traffic has moved, then remove it.
Questions
Can I move a Next.js app from Vercel to Open Source Cloud?
Yes, if it runs as a standard Node.js server. We ran a stock Next.js 16 app here unchanged, with server rendering. Code written for the edge runtime needs to move to Node.js first.
What replaces the storage I used on Vercel?
On Vercel, Postgres and Redis come from marketplace providers and Blob is Vercel’s own. Here they are PostgreSQL, Valkey and MinIO, all open source and all running in your workspace.
Will I be locked in again?
The services are unmodified open source projects, so the same database, key-value store and app can run anywhere else, including on your own servers.
Try it with one app
Pick the smallest app you run on a frontend cloud and move that one first.