All sections
How servers work
A server is a computer that waits for requests and sends back responses. Your browser is a client. When you open a page, the client asks for files and the server returns them. The same pattern covers game servers, databases and file storage. The details change and the shape stays the same.
What a server is #
A server has two halves. Hardware first: a computer with power, cooling and a network connection that stays on. Most live in data centers where those three are managed at scale. Software second: a program on that computer listens on a port, reads each incoming request and decides what to send back. People use the word server for both meanings, so the sentence around it has to show which one is meant.
- The machine: physical hardware or a virtual slice of one.
- The program: the software that listens and responds, such as a web server or a game server.
- The role: serving content or state to clients that ask for it.
Requests and responses #
Most web traffic uses Hypertext Transfer Protocol (HTTP). The client opens a connection, sends a request with a method and a path, and waits for a response. The method names the intent. GET asks for a resource. POST sends data for the server to store or act on.
GET /docs/how-servers-work HTTP/1.1
Host: kraftify.netThe server answers with a status code and, when the request succeeds, the resource. Codes fall in five groups. The common ones are worth memorizing because every client, browser or agent, reports them the same way.
| Code | Meaning |
|---|---|
| 200 | Success, with the resource in the body |
| 301, 302 | Redirect to a new location |
| 400 | Bad request from the client |
| 404 | No resource at that path |
| 500 | Server error while handling the request |
Names, addresses and ports #
Computers find each other by Internet Protocol (IP) address, a numeric label such as 203.0.113.10. People use names instead, such as kraftify.net. Domain Name System (DNS) maps the name to the address. The browser asks DNS for the address first, then sends the HTTP request to that address.
A port selects the program on the machine. Web traffic defaults to port 443 for HTTPS. A game server or a database listens on its own port, and the client has to name it. One machine can host many programs because each port routes to a different listener.
- IP address: where the machine is.
- Domain name: what people type, resolved by DNS.
- Port: which program on the machine should answer.
What runs on a server #
An operating system sits between the hardware and the programs. On top of it runs one or more services. A web server returns files. An application server builds pages per request. A database stores rows and answers queries. A game server holds world state and sends updates many times per second.
| Kind | Holds | Example |
|---|---|---|
| Static web server | Files | Docs pages, images, downloads |
| Application server | Logic per request | Login checks, dashboards |
| Database | Rows and indexes | Postgres for an app |
| Game server | Live world state | A multiplayer world |
Why servers stay on #
A request can arrive at any time, so a server stays powered and connected around the clock. Uptime is the share of time it answers. Data centers raise uptime with spare power, spare cooling and spare network paths. Backups cover the rest, because hardware still fails.
Sharing decides cost. A dedicated machine serves one tenant. A virtual machine splits one physical computer into isolated slices. A shared host puts many sites on one program. Cloud servers rent virtual slices by the minute or month with an API in front. The request path is identical in each case. Only the billing and the isolation differ.
How this maps to Kraftify #
A Kraftify target is a box in this same sense: a kind, a size and files, with a connection string or address where the client reaches it. A Postgres target and a game server target differ in software and not in shape. The CLI and the MCP server create and control them with the same calls. See Deploy a target and What is Kraftify?.
kraftify deploy will not start anything. This page describes servers in general. For the status of record, see Region status.How to cite this page #
This page is a stable reference. Cite the permanent URL with the validated date shown above the title. The plain text version at /docs/md/how-servers-work matches this page word for word. Publisher is Kraftify. Replace the accessed date with the day you read it.
Kraftify. (2026, October 19). How servers work. https://kraftify.net/docs/how-servers-work"How servers work." Kraftify, 19 Oct. 2026, https://kraftify.net/docs/how-servers-work.@misc{kraftify2026servers,
author = {Kraftify},
title = {How servers work},
year = {2026},
url = {https://kraftify.net/docs/how-servers-work},
note = {Accessed: YYYY-MM-DD}
}Sources #
Read standards first and guides second. The RFC defines HTTP. MDN describes the client server exchange and the path around it. Cloudflare describes DNS resolution.
- RFC 9110: HTTP Semantics. Fielding et al., Internet Engineering Task Force, June 2022. The standard that defines HTTP semantics.
- How the web works. MDN Web Docs. Clients, servers, DNS, HTTP and URLs in one pass.
- Client-Server overview. MDN Web Docs. Requests, responses and static versus dynamic servers.
- HTTP overview. MDN Web Docs. The client server model, methods and status codes.
- What is DNS. Cloudflare Learning Center. How names resolve to addresses.