Guides / Concepts explained

What Is a Server? A Plain-English Guide for App Builders

A server is a computer or program that answers requests from other devices. How web servers work, what your app's server does, and what to ask your AI builder.

Mythex Team · 2026-09-29 · 5 min read

A server is a computer — or a program running on one — that waits for requests and answers them. When you open a website, your browser (the client) sends a request across the internet, and a server somewhere sends back the page, the images or the data. Every app you use, from email to online banking, depends on servers doing this millions of times a day.

Why servers matter when you build with AI

When an AI builder makes you an app, part of the code runs in the visitor's browser and part of it usually runs on a server. The server part does the things the browser can't be trusted with or can't do alone:

• Saving and loading data from a database.
• Keeping secrets, such as payment or AI provider API keys, which must never reach the browser.
• Checking permissions — making sure a user can only see and change their own records.
• Talking to other services: charging a card, sending an email, calling an AI model.

Knowing what the server does helps you understand where your app's rules really live, why some changes need a republish, and what you're paying for when you host an app. For the split between the two halves, see frontend vs backend.

An everyday analogy

A server is like the counter staff at a post office. They don't go out looking for customers; they wait. A customer (the client) walks up with a request — "send this parcel," "do you have mail for me?" — and the clerk handles it and hands back a result. One clerk can serve many customers one after another, and a busy post office opens more counters.

The post office also has rules the customer can't override: you have to show ID to collect a parcel. That's the server's job in an app too — the browser can ask for anything, but the server decides what it gets.

How a request reaches a server

When someone visits https://bookings.example.com/schedule:

1. DNS lookup. The browser asks the domain name system which IP address bookings.example.com points to. See how domains and DNS work.
2. Connection. The browser connects to that address, on port 443 for HTTPS, and sets up an encrypted connection. See what HTTPS is.
3. Request. It sends an HTTP request: GET /schedule.
4. Work. The server runs whatever code handles /schedule — perhaps looking up today's bookings in the database.
5. Response. It sends back a status code (200 OK) and the content — an HTML page, or JSON data for the page to display.

All of that usually takes a fraction of a second.

Kinds of servers you'll hear about

Note that "server" means both the machine and the program. "The server crashed" can mean either.

A worked example: a salon booking app

Here's what the server does in a small salon booking app:

• A visitor opens the site. The server (or a CDN in front of it) sends the page files.
• The page asks the server GET /api/slots?date=2026-10-03. The server queries the database for free slots and returns them as JSON.
• The visitor books 14:00. The page sends POST /api/bookings. The server checks the slot is still free — it doesn't trust the browser's word for it — saves the booking and returns 201 Created.
• The server calls an email service with a secret key, stored on the server, to send a confirmation.

If you turned the server off, the page might still load from a CDN, but it couldn't show slots or save bookings.

What a server needs to run well

• Memory (RAM) and CPU. Too little memory and the app crashes under load; too little CPU and it slows down.
• To be running. A server that's switched off can't answer. Some platforms put idle apps to sleep and wake them on the next visit, which saves money but can make the first request slower.
• Configuration and secrets, provided as environment variables.
• Logs — the server's record of what happened, which is where you look first when something breaks.
• Updates and security patches, which managed hosting handles for you.

Common misconceptions

• "The cloud means no servers." The cloud is other companies' servers, rented by the hour or by use.
• "A server is a big special computer." Any computer can act as a server. Your laptop runs one when you open localhost during development.
• "If the button is hidden, users can't do it." Anyone can send requests straight to your server. Permission checks must happen on the server, not only in the page.
• "More servers fixes slowness." Often the real cause is a slow database query or an outside API. Find the bottleneck first.
• "I need to manage a server to have an app." Managed platforms run the servers for you; you deploy code and they handle the machines.

What to ask your AI builder

• "Which parts of this app run on the server, and which run in the browser?"
• "Keep all API keys on the server and read them from environment variables."
• "Check permissions on the server for every request that reads or changes data."
• "Where do I find the server logs, and what do they say about this error?"
• "Does this app need a server at all, or can it be a static site?"
• "What happens to the first request after the app has been idle?"

Servers in Mythex

In Mythex you don't set up or manage servers. While you build, your app runs in a private cloud sandbox for the live preview. When you publish, Mythex deploys it — static front ends as static sites, backends (Node, Python, C#, Java and others) as containers built from a Dockerfile — with no hosting to configure yourself. Mythex picks the machine size when it deploys: by default 1 CPU and 512 MB of memory, with more available on request (up to 1 GB on Free, and up to 2 CPUs, 4 GB and 3 machines on Pro). Published apps sleep when idle and wake on the next visit, and a sleeping app spends nothing on compute. Details are in the docs on API backends and hosting limits, and our guide to web hosting covers the wider picture.