Vercel, Railway, and Supabase solve overlapping but different problems. Start with what your project must do, then add a service when you can explain its job. A simple information page needs somewhere to run. A private reading list also needs persistent data and access rules. A background report needs a runtime and a way to observe failures.
What you will leave with
A small tool plan that names where the app runs, where data lives, who can access it, and how you will monitor cost and recover.
Step 1
Separate files, hosting, and data
Your source files describe the application. Git records their history, and GitHub can host that repository. A hosting service builds or runs the application. A database stores records the application needs to remember. These are different jobs, even when a provider offers several of them.
Write a sentence for each job your project needs. An event information page can begin with files and one host. It does not need visitor accounts or a database simply because those services are available.
Try this instruction
My project must [outcome]. Explain the minimum tools needed for this version. For each, name its job, what I would lose without it, where the data lives, and what could cost money. Identify anything we can defer.
You can explain why every proposed service is needed for the first useful version.
Step 2
Use Vercel to deploy a page or application
Vercel builds and runs websites and applications, with URLs for deployments. Learn the difference between local development, preview, and production. Each environment can have different configuration and access.
Inspect the target before the first deployment. A new project's first deployment can be production. A preview label also does not guarantee isolated data: its credentials may still target the production database. After deploying, open the returned URL and test the main action. The result you see matters more than a green build indicator.
You know the target environment, audience, and services used by the deployment you are testing.
Step 3
Use Railway when its service workflow fits
Railway groups services into a project and provides deployments, variables, and logs. You can deploy from a repository or image. Its workflow can suit an application, supporting service, or background job. Vercel also supports backend workloads, so a strict frontend-versus-backend split is misleading.
Identify how the service starts, where failures appear, and how to stop it. If it writes files that must survive, configure suitable persistent storage. A volume provides persistence; a recovery plan still needs an appropriate backup and restore process.
A manual run succeeds, a failure is visible in logs, and important data survives the intended service lifecycle.
Step 4
Add Supabase when the app needs memory
Supabase provides managed Postgres along with authentication, storage, and other backend capabilities. Add it when your app needs shared records, accounts, or uploads. A table holds a kind of record; a row is one record.
Authentication identifies a user. Authorization decides what that user may access. Test with two accounts so one cannot read or change the other's private records. A login screen is not an access policy. Publishable keys and backend secret keys have different privileges; secret keys bypass row-level security and must never go in browser code.
Create, refresh, edit, and delete work as intended, and cross-user private access fails.
Step 5
Treat configuration as part of the project
Environment variables supply settings without hard-coding every value into source files. Record the names the app needs and which environment each belongs to, but do not commit secret values. A setting exposed to browser code cannot be treated as a secret.
Use sample data while learning. Keep development and production resources distinct where the app can modify records. Preserve schema changes in project history and inspect the database target before applying them. Commands and defaults change, so use current official setup instructions instead of an undated command copied from a tutorial.
You can locate the configuration, identify its target, and explain which values must stay private.
Step 6
Plan cost and recovery before recurring work
Understand subscription charges, usage charges, and resources that remain active between requests. Check current plan pages rather than assuming free forever. An alert is not necessarily a spending cap. Stop controls may take workloads offline, and some charges can continue.
Distinguish four recovery needs: source code, a deployed build, database structure, and stored user data. Rolling back a web deployment does not restore records. Document the last working version, backup location, and restore procedure before storing information you cannot easily replace.
You know how to inspect usage, stop the workload, and recover the relevant kind of failure.
When you get stuck
Too many dashboards before anything works
Return to the first outcome and remove services that do not serve it. Add one capability at a time.
A preview changed real records
Stop writes and inspect its credentials and target resources. Retest using the intended test data.
A secret was exposed
Revoke or rotate it, remove the exposure, and configure the replacement privately. Removing visible text does not invalidate an exposed key.
Terms explained
- Service
- A running component of an application, such as a web server or worker.
- Environment variable
- A configuration value supplied to a program by its environment.
- Persistence
- Keeping needed data beyond the lifetime of a process or deployment.
- Authorization
- Rules determining which actions or records a user may access.
Sources and further reading
The workflow and templates are teaching guidance. The sources below support the underlying tools and concepts; product setup and availability can change.
Take it into your next task
Your completion checklist
0 / 6 checked
Checks are saved on this browser. Mark them only after you inspect the evidence. These are your checks, not an automated certification.