How to Choose a Deployment Platform for Your Vibe-Coded App

A deployment platform is the service that builds your application, runs it on internet-accessible infrastructure, and helps you manage its production configuration.

For a beginner, choosing one can be confusing. Hosting providers use overlapping terms such as serverless, edge, functions, containers, static hosting, managed databases, autoscaling, and continuous deployment. Their home pages often make deployment look like a one-click decision.

The real question is not which platform is best overall.

It is:

Which platform supports the way this particular application needs to run?

A static portfolio, a React application with a few API functions, a long-running Node.js server, and an application with background jobs all have different requirements. A platform that is convenient for one may require awkward workarounds for another.

This article gives you a practical selection process. You will identify what your application does, determine which resources it requires, compare operational features, and recognize when a platform is a poor fit.

The next article in this series will apply these criteria directly to Vercel, Netlify, Render, and Railway.

Start With the Application, Not the Platform

A common beginner workflow is:

1. See a hosting provider recommended in a tutorial.
2. Create an account.
3. Connect a GitHub repository.
4. Attempt a deployment.
5. Discover that the application does not match the platform’s execution model.
6. Add configuration and workarounds until the build passes.

This reverses the selection process.

Before comparing providers, write down the application’s actual requirements. You do not need a formal architecture document. A short deployment brief is enough.

For example:

Application: Appointment booking app

Frontend:
- React
- Built with Vite
- Served as static files

Backend:
- Node.js with Express
- Must remain available to accept HTTP requests

Database:
- PostgreSQL
- Must preserve production data

Other requirements:
- Sends confirmation email
- Runs a reminder job every hour
- Accepts profile images
- Uses three secret API credentials

This brief immediately exposes several decisions.

The frontend can be hosted as static assets. The Express backend needs a compatible server environment. PostgreSQL must run as a durable managed service or on separately managed infrastructure. The reminder process needs scheduled or background execution. Uploaded images need persistent object storage or another durable storage service.

Without this analysis, you might choose a platform because it deploys the frontend easily while overlooking the rest of the system.

Identify Your Application Type

The first selection criterion is the application’s runtime model: how its code executes after deployment.

Static sites

A static site is delivered as prebuilt HTML, CSS, JavaScript, images, and other files. The hosting service does not need to run your application code for every normal page request.

Examples include:

• A portfolio
• Documentation
• A landing page
• A client-side React application that calls an external API
• A statically generated blog

Static hosting is generally the easiest deployment category. The platform builds the project and places the output files on a content delivery network.

Check your framework’s build output. A Vite project commonly produces a dist directory, while other tools may use names such as build, out, or public.

Do not assume that a frontend-only interface means the entire application is static. Login, database access, payment processing, private API calls, and protected business logic require trusted server-side execution somewhere.

Serverless or function-based applications

A function-based platform runs individual server-side functions in response to requests or events. The provider manages much of the underlying server lifecycle.

This model can work well for:

• Form processing
• Authentication callbacks
• Lightweight API routes
• Webhook handlers
• Database queries triggered by requests
• Frameworks designed around serverless functions

Vercel, for example, provides separate local, preview, and production deployment environments and can create preview deployments from non-production branches. Its functions execute in configured regions and should generally be located near their data source to reduce network latency.

Function-based hosting introduces constraints that matter when choosing a platform:

• Execution-time limits
• Memory limits
• Request and response size limits
• Supported runtimes
• Cold-start behavior
• Filesystem behavior
• Region availability
• Background-processing support

Do not assume that code working inside a local Express server can be moved unchanged into serverless functions. Framework adapters can help, but the application’s lifecycle and filesystem assumptions still need review.

Long-running web services

A long-running web service starts a process that remains available to receive requests.

Examples include:

• An Express server
• A Django or Flask application
• A Ruby on Rails application
• A WebSocket server
• A custom API process
• A Dockerized web application

This model is familiar to developers who run a local command such as:

npm start

or:

gunicorn app:app

Platforms in this category commonly ask for:

• A build command
• A start command
• A listening port
• A health-check path
• Environment variables
• An instance size
• A deployment region

Render web services, for example, support build and deployment configuration, environment variables, secrets, health checks, and optional persistent disks.

A long-running service may be a better fit than functions when your application depends on:

• Persistent connections
• A conventional server framework
• Longer request processing
• A custom runtime process
• Greater control over startup behavior

It also means you need to think more directly about service health, scaling, resource usage, and process crashes.

Background workers and scheduled jobs

Not every task should run during a browser request.

A production app may need to:

• Send queued emails
• Process uploaded files
• Generate reports
• Synchronize external data
• Remove expired records
• Retry failed operations
• Run scheduled reminders

These tasks may need a worker process, job queue, or scheduled function.

An app can appear deployable until one of these non-HTTP processes is considered. Before selecting a platform, determine whether it supports the type and duration of background work you need.

Also check how failed jobs are retried. Automatic retries without careful design can create duplicate emails, repeated charges, or repeated database updates.

Check Framework and Runtime Compatibility

A provider may advertise support for JavaScript or Python without supporting every application architecture built with that language.

Record the following:

• Programming language
• Runtime version
• Framework and version
• Package manager
• Build command
• Start command
• Required system packages
• Native dependencies
• Port behavior

A basic Node.js deployment brief might say:

Runtime: Node.js 22
Package manager: npm
Install command: npm ci
Build command: npm run build
Start command: npm start
Health endpoint: /health

Confirm each value from your repository rather than asking an AI assistant to guess.

Inspect:

• package.json
• Lockfiles such as package-lock.json or pnpm-lock.yaml
• Framework configuration
• Dockerfile, when present
• Runtime-version files
• Existing deployment configuration

Then compare those requirements with the provider’s current documentation.

Pay particular attention to version support. A platform may select a default runtime that differs from your laptop. An application built locally with one Node.js or Python version can fail when the remote builder chooses another.

Pinning a supported runtime version makes deployments more repeatable, but you remain responsible for updating it when that version approaches end of support.

Decide Where the Database Will Run

The database decision can eliminate unsuitable platforms quickly.

Ask:

• Does the app need a database?
• Which database engine does it use?
• Will the platform provide it?
• Will you use a separate managed database?
• Which region will store the data?
• How are backups handled?
• How will schema migrations run?
• What happens when the database reaches its storage or connection limits?

Your application host and database do not need to come from the same provider. However, keeping them in compatible regions can reduce latency and simplify networking.

A function or server that runs far from its database adds network delay to every query. A page that performs many sequential queries can amplify that delay.

Also distinguish between a database and local file storage. Writing a JSON file or SQLite file inside the deployed application directory may appear to work temporarily, but many cloud execution environments use ephemeral filesystems.

Render documents that service filesystems are ephemeral by default: local changes are lost when a service restarts or redeploys unless supported persistent storage is attached. Railway similarly distinguishes ephemeral deployment storage from volumes intended for data that must persist.

For production data, use storage that is explicitly designed to persist. Do not infer durability from the fact that a file remained available during one test.

Separate File Storage From Application Storage

Applications often need to store:

• User avatars
• Attachments
• Generated reports
• Product images
• Video or audio
• Export files

These files should usually not be stored in the application’s deployment directory.

A new deployment may replace that directory. Multiple running instances may not share the same local files. Function environments may not preserve writes between invocations.

Object storage is typically a better fit for user uploads because it is designed for durable files and can be accessed independently of a particular application instance.

Before choosing a platform, determine:

• Whether it provides suitable object storage
• Whether you will connect an external storage provider
• Maximum upload and request sizes
• Access-control options
• Supported regions
• Data-transfer charges
• Backup or versioning options

Do not make an upload directory persistent merely because it is the fastest workaround. Consider what happens when the service scales to two instances or when a user uploads an unsafe file type.

Look for Separate Deployment Environments

At minimum, you should distinguish local development from production. As the application becomes more important, you may also need preview or staging environments.

A useful workflow is:

Local development
        ↓
Preview deployment for a branch or pull request
        ↓
Staging validation
        ↓
Production release

Preview environments allow you to test deployed code without replacing the public production version.

Vercel documents local, preview, and production environments, with preview deployments commonly created for branches or pull requests. Netlify supports deployment-context configuration and environment-variable controls, including controls for whether untrusted deploys can access sensitive variables.

When comparing platforms, check whether environments can have separate:

• Domains
• API keys
• Databases
• OAuth callback URLs
• Build settings
• Feature flags
• Access restrictions

A preview deployment should not automatically receive every production secret. It also should not send test emails to real customers or modify production records unless that behavior is intentional and protected.

Evaluate Environment-Variable and Secret Management

Every realistic application has configuration that changes by environment.

Examples include:

DATABASE_URL
EMAIL_API_KEY
SESSION_SECRET
PUBLIC_APP_URL
LOG_LEVEL

A platform should let you store these values without committing them to Git.

It should also let you control where they are available. Some variables are required during the build. Others should exist only while trusted server code is running.

Vercel supports environment variables scoped to deployment environments, including preview and production. Netlify distinguishes build variables from variables used by runtime functions and warns against committing sensitive local values to the repository. Railway service variables are exposed to build and runtime contexts and can be scoped or referenced across services.

When evaluating secret management, ask:

• Can values differ between development, preview, staging, and production?
• Can access be limited to specific services?
• Are changes recorded in an audit log?
• Can team permissions restrict who reads or edits secrets?
• Does changing a value require a redeployment?
• Can untrusted pull requests access sensitive variables?
• How are multiline keys or certificates handled?

Remember that a platform can store a secret securely while your code still exposes it. Any value included in browser-delivered JavaScript should be treated as public.

Compare Deployment and Rollback Workflows

A beginner-friendly platform should make the normal deployment path clear.

A Git-based workflow commonly looks like this:

1. Push a branch.
2. The platform detects the change.
3. It installs dependencies.
4. It runs the build.
5. It creates a preview deployment.
6. You verify the preview.
7. You merge into the production branch.
8. The platform creates a production deployment.

Vercel’s Git integrations can automatically deploy branch pushes and production-branch changes, while providing preview deployment URLs. Netlify can also trigger builds and deployments from connected Git repositories.

Check what happens when the build fails. A good workflow should preserve the current working production release instead of replacing it with a broken build.

Then investigate rollback support:

• Can you restore a previous deployment?
• Does rollback change only application code?
• Are environment-variable changes restored?
• What happens to database migrations?
• Can a deployment be promoted from staging?
• Is deployment history retained?
• Can you identify the Git commit behind each release?

A code rollback is not the same as a complete system rollback. If a release changed the database or external data, restoring the previous application image may not be sufficient.

Consider Regions and User Location

A region is the geographic location where the provider runs a service or stores data.

Region choice affects:

• Network latency
• Database response time
• Data residency
• Service availability
• Disaster-recovery options
• Communication between components

The best region is not always the one closest to you. It may be the one closest to your primary users or database.

Keep tightly connected components near one another. A backend in one continent and a database in another can add noticeable delay to every database operation.

Render currently documents regions in the United States, Germany, and Singapore, and recommends selecting regions to reduce latency between users, applications, and datastores. Region availability changes over time, so verify current provider documentation when making the actual deployment decision.

For an early project, choosing one suitable region is often enough. Multi-region architecture adds complexity and does not automatically solve database consistency or recovery.

Understand Scaling Before You Need It

Scaling means increasing the resources available to handle greater demand.

Two common approaches are:

• Vertical scaling: give one instance more CPU or memory.
• Horizontal scaling: run more instances.

A platform may scale automatically, manually, or not at all on a particular plan.

Render, for example, supports manual and automatic scaling for eligible services and distributes incoming traffic across multiple instances.

Do not choose a platform only because it advertises large-scale capacity. For a first launch, predictable behavior and understandable limits may matter more.

Instead, ask:

• What happens when traffic exceeds the current capacity?
• Is scaling automatic?
• What triggers it?
• Can the database support the additional connections?
• Will costs grow unexpectedly?
• Does the application store session state in local memory?
• Can multiple instances safely process the same job?

An application that stores login sessions or uploaded files only on one local instance may break when a second instance is added.

Calculate the Whole Cost, Not the Starting Price

A free or low-cost entry plan can be useful for learning, but the displayed starting price rarely represents the complete production cost.

Potential charges include:

• Build minutes
• Runtime CPU and memory
• Function invocations
• Execution duration
• Network transfer
• Image transformation
• Log retention
• Database compute
• Database storage
• Backups
• Persistent disks
• Object storage
• Custom domains
• Team members
• Additional environments

Also check what happens when a limit is reached. The provider might stop the service, reject requests, charge overages, or require an upgrade.

Free plans may impose restrictions that make them unsuitable for persistent production use. For example, Render’s current free-service documentation states that free web services cannot attach persistent disks and that free PostgreSQL databases expire after a limited period. Features and limits change, so confirm them immediately before launch rather than relying on an older tutorial.

Estimate cost based on realistic usage:

Expected monthly users: 1,000
Average page requests per user: 20
API requests per user: 10
Database size after six months: 2 GB
Uploaded files per month: 5 GB
Required log retention: 14 days
Required environments: preview and production

You do not need a perfect forecast. The purpose is to identify which resources could create cost.

Set budgets and usage alerts when the provider supports them.

Evaluate Logs, Metrics, and Health Checks

Deployment is easier when the hosting provider shows what the application is doing.

At minimum, look for:

• Build logs
• Runtime logs
• Deployment history
• Request errors
• Resource metrics
• Health checks
• Alerts or integrations
• Log export options

A build log helps explain why installation or compilation failed. A runtime log helps investigate failures after deployment. A health check allows the platform to determine whether a service can handle requests.

Render web services, for example, support a configurable health-check path. Netlify documents logs and metrics for deployed functions.

Check retention limits. If logs disappear quickly, you may need an external logging or error-tracking service.

More logs are not always better. Never log passwords, session tokens, API credentials, payment details, or unnecessary personal information.

Review Security and Team Controls

Even a solo project benefits from basic account and deployment security.

Compare:

• Multifactor authentication
• Git-provider permissions
• Team roles
• Deployment approvals
• Secret access controls
• Audit logs
• Private networking
• Custom-domain verification
• TLS and HTTPS support
• Security headers
• Dependency and build isolation

Also examine how preview deployments are protected. A random-looking preview URL is not an access-control system. A preview may expose unfinished features, test data, internal interfaces, or production-connected actions.

For sensitive applications, determine whether previews can require authentication or network restrictions.

The platform secures its infrastructure, but you remain responsible for your application’s code, authorization rules, dependencies, data handling, and secret usage.

Check Portability and Lock-In

Platform-specific features can reduce setup work. They can also make migration harder.

Examples include:

• Proprietary function APIs
• Provider-specific databases
• Specialized edge runtimes
• Custom configuration formats
• Integrated image services
• Platform-specific queues
• Built-in authentication

Lock-in is not automatically bad. A managed feature may save substantial development and maintenance effort.

The question is whether you understand the tradeoff.

Before committing to a provider-specific feature, ask:

• What problem does this feature solve?
• What would replace it on another provider?
• Is the application using standard APIs?
• Can data be exported?
• Are backups available in a portable format?
• How much code depends on this provider?
• Is the convenience worth the migration cost?

A Docker-compatible application with an external PostgreSQL database may be more portable than one built entirely around proprietary services. It may also require more configuration and operational work.

Choose deliberately rather than trying to eliminate all dependency on a provider.

Use a Weighted Decision Matrix

A decision matrix prevents one attractive feature from dominating the choice.

Score each platform from 1 to 5 for criteria that matter to your application.

Criterion	Weight	Platform A	Platform B	Platform C
Framework compatibility	5
Backend runtime fit	5
Database support	5
Background jobs	4
Preview deployments	3
Secret management	5
Logs and monitoring	4
Rollback workflow	4
Region availability	3
Expected cost	4
Documentation quality	3
Portability	2

Multiply each score by its weight and compare the totals.

Do not treat the final number as an objective truth. Use it to expose assumptions and identify missing research.

A platform that scores well overall should still be rejected if it fails a mandatory requirement. For example, a platform without appropriate background processing is not suitable when the application’s central workflow depends on a long-running worker.

Recognize Common Selection Mistakes

Choosing the platform recommended by the AI assistant

An assistant may recommend a provider because it appears frequently in training material, not because it matches your architecture.

Ask it to explain:

• Which application requirements it identified
• Which platform limits it checked
• Which official documentation supports the recommendation
• Which tradeoffs remain
• What would make another platform preferable

Verify the response yourself.

Optimizing only for the first deployment

A provider may make the initial deployment easy while making databases, scheduled work, monitoring, or recovery difficult.

Evaluate the first six months, not only the first ten minutes.

Assuming every filesystem is permanent

Cloud filesystems are often ephemeral. Verify persistence explicitly before storing user data.

Treating the free plan as a production guarantee

Free tiers can change, pause inactive services, exclude backups, limit resources, or provide no meaningful service guarantee.

Use them to learn, prototype, or serve workloads that can tolerate those restrictions.

Ignoring exit and recovery options

Before storing important data, determine how to export it, back it up, and restore it elsewhere.

The best time to learn that a backup format is incomplete is before an incident.

A Practical Platform-Selection Process

Use this sequence for your first production app.

Step 1: Create an application inventory

List the frontend, backend, database, background jobs, file storage, external APIs, and secrets.

Step 2: Identify non-negotiable requirements

Examples:

• Must run a long-lived Node.js process.
• Must support PostgreSQL.
• Must provide scheduled jobs.
• Must run near users in Southeast Asia.
• Must preserve uploaded files.
• Must create protected preview deployments.

Step 3: Record runtime and build requirements

Confirm versions, package managers, commands, ports, and system dependencies from the repository.

Step 4: Estimate expected usage

Estimate requests, storage, data transfer, database size, build frequency, and team size.

Step 5: Compare current official documentation

Check supported runtimes, limits, regions, pricing, storage behavior, security controls, and rollback options.

Do not rely solely on comparison posts or old video tutorials.

Step 6: Deploy a small representative version

Test more than the home page. Include:

• One server route
• One database query
• One environment variable
• One production build
• One error-log check
• One redeployment
• One rollback attempt
• One file or background task when relevant

Step 7: Document the decision

Write down:

Chosen platform:
Reason:
Mandatory requirements satisfied:
Known limitations:
Estimated cost drivers:
Database location:
Secret-management approach:
Deployment workflow:
Rollback approach:
Reason for rejecting alternatives:

This record will be useful when requirements change or another developer joins the project.

AI Prompt for Comparing Candidate Platforms

The following prompt can help organize research. It should not replace checking official documentation.

Goal:
Help me compare deployment platforms for this application.

Application context:
- Frontend:
- Backend:
- Runtime and version:
- Database:
- Background jobs:
- File storage:
- Expected users and traffic:
- Primary user region:
- Required deployment environments:
- Sensitive data handled:

Constraints:
- Use current official documentation only.
- Do not assume that local files are persistent.
- Distinguish build-time variables from runtime secrets.
- Identify execution, storage, database, and networking limits.
- Do not recommend a platform that fails a mandatory requirement.
- Mark any information that could not be verified.

Expected output:
1. Mandatory requirements
2. Comparison table
3. Major tradeoffs
4. Cost drivers
5. Security and recovery concerns
6. Recommended proof-of-concept tests
7. Official documentation references

Verification:
For every platform-specific claim, name the exact official documentation page
that should be checked before deployment.

Review the result for unsupported claims, outdated limits, and assumptions about your architecture.

Choosing the Simplest Platform That Fits

Your first deployment platform should not provide every possible cloud feature. It should support your current requirements without forcing you to disguise the application as something it is not.

A good first choice usually offers:

• Direct support for your framework and runtime
• Clear Git-based deployment
• Separate preview and production configuration
• Safe secret storage
• Appropriate database and file-storage options
• Understandable logs
• A practical rollback workflow
• Regions suitable for your users and data
• Costs you can monitor
• Documentation you can follow without guessing

Convenience matters, especially for a beginner. Architectural fit matters more.

Begin with your application inventory, identify mandatory requirements, and verify the platform with a representative deployment. That process will produce a more reliable decision than choosing whichever provider appears most often in tutorials.

The next article compares Vercel, Netlify, Render, and Railway using these criteria.

Deployment Platform Selection Checklist