Skip to content

What is a Server? Cloud, Hosting, and Where Your Code Lives

Demystifying servers, cloud hosting, and serverless — understand where your app actually runs.

8 min readservers, cloud, hosting, infrastructure, fundamentals
Copy The Prompt First

Use the lesson prompt before you improvise

This lesson already contains a scoped prompt. Copy it first, replace the task and file paths with your real context, and make the agent stop after one reviewable change.

Matching prompts nearby

29

When you finish this lesson prompt, use the related prompt set to keep the same supervision pattern on the next task.

This lesson promptWhat is a Server? Cloud, Hosting, and Where Your Code Lives

Demystifying servers, cloud hosting, and serverless — understand where your app actually runs.

Preview
"Help me choose the safest hosting model for this project.
1. Explain whether this app should use static hosting, managed platform hosting, or serverless functions
2. Tell me what parts of the app run where
3. List the operational tradeoffs: logs, scaling, cold starts, cost, and simplicity
4. Tell me which environment variables or secrets must be configured
5. Stop before making infra, billing, or region changes w...

When you deploy an app and someone visits it from across the country, where is your code actually running? What is this "server" people keep mentioning? And what does "the cloud" actually mean?

A Server Is Just a Computer

A server is a computer — not that different from the one on your desk — that is set up to stay online and respond to requests from other computers.

When you visit a website, your browser sends a request (as we learned in the last lesson) to a server somewhere. That server runs the code that powers the website, fetches the right data, and sends back a response.

Think of it this way: your laptop is optimized for one person sitting in front of it. A server is optimized for many people connecting over the internet at the same time.

"The Cloud" — It's Just Someone Else's Computer

"The cloud" simply means computers owned and managed by someone else, that you rent over the internet. Instead of buying your own server, plugging it in, and maintaining it, you pay Amazon (AWS), Google (Google Cloud), or Microsoft (Azure) to use their servers.

There is no magic here. You are still using computers. You are just renting them instead of owning them.

Why this matters: When your AI tool says "deploy to the cloud," it means "put your code on someone else's server so people can access it via the internet." When you use services like Vercel, Netlify, or Replit to deploy your app, they're handling the server part for you.

The Three Ways Your Code Can Live on the Internet

1. Traditional Hosting (Renting a Whole Server)

You rent a server and manage everything yourself: the operating system, security updates, and the software your code depends on.

Analogy: Renting an apartment. It's yours to use, but you're responsible for keeping it up.

Used by: Teams that want direct control. Usually more work than a beginner needs.

2. Platform Hosting (Managed for You)

This is where most vibe coders should start. Services like Vercel, Netlify, Replit, and Railway handle the server management. You give them code; they handle deployment, uptime, and most of the operational work.

Analogy: Living in a hotel. You show up with your suitcase (your code), and everything else is handled — housekeeping, maintenance, the front desk.

Used by: Most modern web applications, including many from professional developers. This is the recommended approach for vibe coders.

3. Serverless (Running Code on Demand)

"Serverless" does not mean there is no server. It means you do not manage one directly. Your code runs only when it is needed.

Analogy: Using a taxi instead of owning a car. You don't maintain it, insure it, or park it. It shows up when you need it and disappears when you don't.

Used by: APIs, backend functions, and event-driven tasks. Many vibe coding tools use serverless under the hood without you knowing.

Where Your App Actually Lives: A Real Example

Let's say you build an app with Bolt and deploy it. What usually happens is:

  1. Frontend code gets pushed to a CDN so users can load it from a nearby location.
  2. Backend code runs on managed servers or serverless functions.
  3. Data lives in a database service running somewhere else.

Your "one app" actually lives in multiple places, all coordinated seamlessly. This is completely normal and is how virtually every modern web app works.

Hosting Services Vibe Coders Should Know

Here's a quick reference for the hosting services you're most likely to encounter:

Vercel / Netlify are common defaults for web apps.

Replit keeps coding and hosting in one place.

Railway is useful when you need more backend control.

Supabase is not your frontend host, but it often handles database, auth, and storage.

"But What About AWS and Google Cloud?"

You might hear about AWS, Google Cloud, or Azure. These are the raw infrastructure providers behind much of the internet.

As a vibe coder, you usually do not want to start there directly. Services like Vercel and Supabase already sit on top of them and give you a simpler interface.

Think of it this way: AWS is like buying raw steel and welding your own car. Vercel is like buying a car from a dealership. Both get you on the road, but one is dramatically simpler.

How Much Does Hosting Cost?

For small projects and MVPs, hosting is often free or close to it. You usually start paying when traffic, storage, or advanced features become real.

Try this now

  • Identify where your current app's frontend, backend functions, and database are actually hosted.
  • Look in your deployment dashboard and note the provider, project, and region.
  • Check whether your app is mostly static hosting, managed platform hosting, or serverless functions.
  • Ask your agent to describe your live architecture in plain English without using cloud buzzwords.

Prompt to give your agent

"Help me choose the safest hosting model for this project.

  1. Explain whether this app should use static hosting, managed platform hosting, or serverless functions
  2. Tell me what parts of the app run where
  3. List the operational tradeoffs: logs, scaling, cold starts, cost, and simplicity
  4. Tell me which environment variables or secrets must be configured
  5. Stop before making infra, billing, or region changes without my approval

Optimize for low operational burden and easy rollback."

What you must review yourself

  • Whether the hosting choice matches the app's actual complexity and traffic
  • Whether logs, environment variables, and deploy history are accessible before you need them in an emergency
  • Whether your data is running in the right region or legal jurisdiction for the project
  • Whether the agent is suggesting infrastructure that is harder to operate than the product deserves

Common mistakes to avoid

  • Treating "the cloud" like a magic destination. You still need to know which service runs which part of your app.
  • Choosing infrastructure for ego instead of fit. Most early products need boring platform hosting, not custom cloud architecture.
  • Ignoring operational visibility. If you cannot find the logs, environment settings, and deployment history, you are flying blind.
  • Assuming serverless means no operational tradeoffs. It removes some work, but it still comes with costs, limits, and performance characteristics.

Key takeaways

  • A server is just a computer running your code for other people over the internet
  • Cloud hosting means renting someone else's managed computers instead of owning your own
  • Platform hosting is usually the right default for vibe coders because it minimizes operational drag

What's Next

Servers process requests and return responses. But often, your app needs to talk to other apps — a payment processor, an email service, a weather data provider. That communication happens through APIs, and understanding them is one of the most useful concepts you can learn. That's next.