Skip to content
What Deployment Is

02.02 · Concept · Free

What a Server Actually Is

Describe what a server keeps, runs and delivers, and why that is different from the machine under your desk.

No video curated for this lesson yet

This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.

The written notes below cover this idea in full - you lose nothing by reading instead of watching.

A server is a role: keeping shared state, running request-handling processes, and returning network responses under a stable identity. It might be hardware, a VM, a container, or managed infrastructure. The key difference from a laptop is that users can depend on it without depending on one developer’s machine.

What this lesson answers

  • what does a server actually do
  • server versus laptop in deployment
  • is a server hardware or a process

Notes

Server — A server exists to keep shared state, run long-lived services, and deliver responses over a network; without it, users would depend on one person’s local machine being powered on, reachable, secure, and consistent.

Key Concepts: - A server is defined by its role, not its shape: a U rack machine, an AWS EC2 instance, and a Raspberry Pi can all serve HTTP responses on port or . - A server keeps shared resources such as files, database rows, sessions, or cached objects; for example, Postgres stores table data in files under a data directory like `/var/lib/postgresql/data`. - A server runs processes that wait for requests, such as `nginx` listening on TCP port or a Node.js process listening on port . - A server delivers responses using protocols: an HTTP server receives `GET /index.html` and returns a status like `200 OK` plus bytes for HTML, JSON, CSS, or images. - A personal laptop usually serves one user interactively, while a deployed server may handle , , or network requests from many users. - A server often runs without a screen or keyboard; Linux services are commonly managed by `systemd`, for example `systemctl restart nginx`. - “The server” can mean one process, one virtual machine, one container, or a fleet behind a load balancer, such as Kubernetes Pods serving the same app. - Server reliability depends on stable network identity, such as a DNS name `api.example.com` pointing to an IP address where clients can send requests.

Watch For: - Calling your laptop “the server” during development can hide the fact that `localhost:3000` only works on your machine, not for users across the internet. - Saving uploaded files to a container’s local disk, such as `/tmp/uploads`, can lose data when Kubernetes replaces the Pod. - Assuming a server is always one physical computer breaks down on platforms like AWS Lambda, where one function may run across many short-lived execution environments. - Confusing the server process with the database can cause bad diagrams: an Express app may run on port while Postgres separately listens on port .

Production Connection: - Kubernetes runs server workloads as Pods, such as replicas of an `nginx` Deployment behind a Service with one stable virtual IP. - Cloud Run deploys a container that becomes an HTTP server when it listens on the required `5432$ and writing database changes to disk using WAL.

Common questions

What makes something a server?
Something is a server when it provides shared resources or responses to other machines over a network. The form is secondary: it may be a physical box, cloud instance, container, function, or process. What matters is that clients can reach it and it performs a service for them.
Why is localhost not a real deployed server?
Localhost only refers to the machine making the request. When your app listens on localhost during development, it is reachable from your computer, not from users elsewhere. Deployment gives the service a network address, managed runtime, and operational environment that other clients can consistently reach.
Is the database part of the server?
The database may be a separate server from the application. An app process can accept HTTP requests while a database process stores and retrieves durable state. Treating them as the same thing leads to confused architecture diagrams and poor operational decisions, especially around storage, backups, and connectivity.