Where to Deploy a Vibe-Coded App: A One-Afternoon Platform Test

Search for where to deploy a vibe-coded app and you get the same lists: Railway, Render, Fly.io, Vercel, plus whoever wrote the list. They compare price, regions, and free tiers. None of that tells you what you will learn the first night the app returns a 502 and the only thing you changed was a prompt.

A vibe-coded app changes faster than anyone reviews it, so the platform has to make every release easy to inspect. You can find out in one afternoon: deploy the same small app on two or three candidates, break it on purpose, and score what you see.

Make it small but real: a web page, an API route that writes to PostgreSQL, one secret, and one migration. Deploy the same commit on every candidate. For each platform, write down the minutes to the first working URL and any file you changed only for that platform. A platform-specific rewrite is a cost you will pay again with every app.

• Build. Does it install from your lockfile, handle a Dockerfile when you need one, and show the exact line where a build failed?
• Runtime. Can you set the port, start command, memory, and environment variables without editing code?
• Data. Is PostgreSQL included? How are connections, backups, and restores handled, and who can see the credentials?
• Delivery. Do you get HTTPS, custom domains, logs, and a way back to the last working version? How many steps is that?
• Control. Who can deploy, read secrets, see logs, or delete things?

No platform solves production for you. The app still owns its data model, authorization, and migration safety, which is what five checks before your first customer is for.

Deploy a known-good commit. Then push two bad releases, one at a time:

• A missing required variable, so the app crashes on start.
• The wrong port, so the app starts but nothing answers.

For each one, watch three things. Does the platform mark the release failed, or does it stay green? Does the previous version keep serving? Do the logs name the cause? A platform that shows a green badge while visitors get errors will cost you more over a year than one that deploys thirty seconds slower. Then get back to the good version and count the steps.

Most platforms now ship an MCP server. Railway publishes one, and Fly.io's flyctl includes an experimental one. So "does it have MCP?" is no longer the question. Ask these instead:

• What can the agent do in one call? Only deploy, or also provision the database, set variables, and return the URL?
• What authority does it hold? Read and write should be separate permissions, and destructive tools should be marked as destructive so the client can ask first.
• What evidence does it return? Insist on the build result, the health status, and the exact URL it tested, not just "done."

Prioritize portability first, then control. A tool that works across clouds should deploy from standard inputs such as a Dockerfile or a lockfile, let you choose the cloud and region for each app, keep separate credentials for each cloud, and record what the agent changed. Anything that needs a vendor-specific runtime or config file will not move.

Check these in order:

• Standard inputs. Could the same commit deploy somewhere else without editing code? A platform-specific file is a cost you pay again on every cloud.
• Your choice of cloud and region. You set it for each app. The agent should not guess it.
• Separate credentials. One account or token per cloud, with the smallest permission that does the job, and short-lived where the provider allows it.
• A trail. Which tool calls the agent made, who approved them, and what changed.
• The same gate everywhere. The checks before a deploy should not depend on which cloud you target.

Infrastructure-as-code tools such as Terraform and Pulumi are the usual way across clouds. An agent can write and run them, but then it holds credentials for every cloud, which makes the approval rules below matter more, not less.

ProductEcho is not a multi-cloud tool. It runs your app on its own managed platform on AWS, so you do not choose the cloud. Apps and databases run in US East (N. Virginia) by default, and Asia-Pacific (Mumbai) or the EU (Frankfurt) are available on request. We confirm a requested region in writing before provisioning, and your app and database then stay in it. What it does keep portable: it builds from your Dockerfile or detects the framework from your source, and it does not ask for a ProductEcho-specific build file in your code.

Verification is deterministic when the same commit always gets the same pass or fail, with no model judging it. In practice that is a build from a lockfile, automated tests, type checks and a security scan, run by a CI system such as GitHub Actions, GitLab CI or Jenkins before the deploy step. The deploy tool is rarely where those checks live, so add them and make the agent wait for them.

Ask each platform three questions:

• What runs before the deploy? Is the check rule-based, or does a model decide?
• Does a failure stop the release? Or does it only warn?
• What comes back afterwards? The build result, the health status and the exact URL it tested, not just "done."

ProductEcho checks that a project is deployable, not that it works. It inspects your source with fixed rules and no model: it finds the framework, the port, the build strategy and the environment variables the app expects, and it lists each project in a monorepo. It does not run your tests. A release shows Ready when its containers are running, and ProductEcho does not call a health route your app defines. So run your tests and scans first, then ask the agent to open the live URL and report what came back. In the demo recording Claude Code does this itself: it requests the app's health endpoint and reads back the database status.

For MCP deployment platforms, the approval step is usually enforced by the AI client, not the platform. Claude Code and Cursor ask before running an MCP tool by default, and Codex always asks for a tool marked destructive. So check that the platform marks its deploy tools as destructive and that your client has approvals switched on.

In the vendor docs we read in October 2026, Railway marks destructive actions at the protocol level and tells you to review them before approving. Vercel says to always enable human confirmation. Render warns that triggering deploys and changing environment variables are destructive operations, and describes no approval step. Heroku's and Fly.io's MCP pages describe none either. Vendors change these pages, so check the current docs. The six-platform comparison has the table.

ProductEcho flags deploys, environment and settings updates, pauses, deletes and domain removals as destructive, so a client that honours the flag asks first, and its OAuth sign-in separates read from write access. It has no approval step of its own on the server: a client set to run tools without asking will deploy without asking. Three habits keep the review meaningful:

• Leave approval on for deploy_application, update_application_env and every tool whose name starts with delete_. The guides for Claude Code, Cursor and Codex show where the setting is.
• Let reads such as get_workspace_info, list_applications and get_application_status run without asking. They change nothing.
• Read what each prompt says it will do. The sign-in grants write access, and that includes deleting apps and databases.

After the test, add up the database, idle staging, outbound traffic, and seats. A low entry price says little about a workload with data. Keep your notes in the repository so you can revisit the decision when traffic or compliance needs change.

• Build. It inspects the repository first, lists each project it finds, and builds automatically or from your Dockerfile.
• Runtime. Port, CPU, memory, and environment variables are settings on the app.
• Data. PostgreSQL is managed, with TLS required. You pick a compute size, storage can grow, and you can pause the database without losing its data.
• Delivery. Every app gets a public HTTPS address with a managed certificate, and you can add custom domains: you publish two DNS records and the certificate is issued for you. A release shows as Deploying, Ready, or Deploy failed with a reason. A container app's Logs tab keeps seven days of what it printed, with filters and a live view, and your agent can read the same logs and the output of a failed build. There is no rollback button: to go back, redeploy the previous source.
• Control. Pro adds team roles. MCP access uses OAuth scopes, with separate read and write permissions for applications, databases, workspace info, and logs, and destructive tools are marked as destructive. Logs are never granted to viewers.

Run the same test on ProductEcho. The Free plan covers it, with no credit card. Connect your agent to start.