Before anything technical, let’s pin down the word itself.

In everyday Docker usage, a service is a named, self-contained description of one piece of your application — what image it should run from, what it should be called, which ports it needs, what other services it depends on, and how it should behave if something goes wrong. “Defining a service” simply means writing down that description in one place, usually inside a configuration file, so Docker knows exactly how to create, connect, and manage that piece consistently, every single time.

A single application is almost always made up of several services working together. A typical web application, for example, might need a service for the web server, a separate service for the database, and perhaps a third for a caching layer. Each of these runs as its own independent container, but they’re all described together, as one coordinated group, so starting or stopping the whole application is a single, predictable action rather than juggling several unrelated pieces by hand.

It would be simpler to put everything in one container. Here’s why that usually backfires.

It’s technically possible to cram a web server, a database, and a background worker into a single giant container. In practice, this quickly becomes painful. If the web server crashes, the whole thing — including the database — goes down with it. If you need to update just the caching layer, you have to rebuild and restart everything, database included. Scaling becomes clumsy too: if your web traffic spikes but your database is perfectly fine, you can’t easily add more web capacity without also duplicating the database along with it.

Splitting the application into separate services solves each of these problems at once. Each service can be started, stopped, updated, rebuilt, or scaled completely independently of the others. A crash in one service doesn’t necessarily bring down the rest. And because each service is defined separately, its exact responsibilities and requirements are documented clearly, rather than tangled together inside one enormous container.

Services aren’t described in random places — Docker has one central, standard file for them.

Services are typically defined together inside a single configuration file, most commonly written in a human-readable format that lists each service by name, followed by its settings, indented underneath it. This file lives alongside your project’s code and acts as a single source of truth: anyone on the team can open it and immediately see every piece the application is made of, what each piece needs, and how they relate to one another.

This approach is often described as “infrastructure as configuration” — instead of someone manually typing out a long series of individual setup steps every time the application needs to run, the entire setup is captured once, in a readable file, and Docker recreates it identically every single time that file is used.

A service definition is built from a small set of recurring building blocks.

While the exact details vary, almost every service definition answers the same handful of questions about that piece of the application.

Each of these settings maps to a real, practical concern. The “name” becomes how other services find and talk to this one over the network. The “dependencies” setting prevents a web server from starting up and immediately failing because the database it needs isn’t ready yet. The “restart policy” decides whether a crashed service quietly comes back on its own or stays down until someone investigates.

A service’s name isn’t just a label — it becomes a genuinely usable address.

One of the most useful side effects of defining services together is automatic name-based networking. When services are defined and started as a group, Docker places them on a shared private network and gives each one the ability to reach the others simply by using their service name, as though that name were an address on the internet. A “web” service can talk to a “database” service just by referring to it as “database” — no manual network configuration, no memorizing changing numeric addresses.

flowchart LR
    A["web service"] -- "reaches by name: database" --> B["database service"]
    A -- "reaches by name: cache" --> C["cache service"]
    subgraph SharedNetwork["Shared Private Network"]
      A
      B
      C
    end
    style A fill:#fef2f2,stroke:#dc2626
    style B fill:#fafafa,stroke:#171717
    style C fill:#fafafa,stroke:#171717
        

This is a major reason services are defined together rather than started as completely separate, unrelated containers. Grouping them lets Docker set up this shared network and naming automatically, so the services genuinely behave like coordinated teammates instead of strangers that happen to be running on the same machine.

Just because services are defined together doesn’t mean they should all start at exactly the same moment.

A web application service usually needs its database to be available before it can properly function. Docker allows a service definition to declare that it depends on another service, which controls the order containers are created and started in — ensuring, for example, that the database container is told to start before the web container.

Because a service is a definition rather than a single fixed container, it can be multiplied.

A powerful consequence of defining an application in terms of services, rather than individual containers, is that a single service definition can be used to run more than one identical container at once. If a web service is getting more traffic than one container can comfortably handle, that service can be scaled up to run several identical containers side by side, all created from the exact same definition, all reachable under the same service name.

This is only possible because a service is a reusable description, not a one-off, manually configured container. Scaling simply means asking Docker to create more (or fewer) containers from that same description.

A service definition also decides what happens the moment something goes wrong.

Software crashes. A well-defined service anticipates this by including a restart policy — a rule telling Docker what to do if that service’s container stops unexpectedly. Common choices include never restarting automatically, always restarting no matter what, or restarting only if the container exited because of an actual failure rather than a deliberate, intentional stop.

Choosing the right restart policy for each service is part of properly defining it. A background worker processing important tasks usually benefits from aggressive automatic restarting, while a one-time setup task that’s meant to run once and finish would be actively harmed by being restarted endlessly.

A service that forgets everything on every restart isn’t very useful for anything holding real data.

By default, anything written inside a container’s own filesystem disappears the moment that container is removed. For stateless services, like a web server that doesn’t itself hold important data, this is completely fine. But a database service obviously can’t lose its data every time it restarts. This is why service definitions typically also declare storage — attaching a persistent volume, or occasionally a bind-mounted folder, at the exact path where that service keeps its important files, so the data survives long after any individual container is replaced.

A short checklist that separates clean, maintainable service definitions from tangled, fragile ones.

This pattern of defining services shows up in nearly every modern web application, regardless of the language or company building it.

Not exactly. As explained in Chapter 1, a service is the definition — the job description — while a container is the actual running instance created from it. One service can produce several containers, as covered in Chapter 7.

Typically yes, for a single application, as discussed in Chapter 3 — keeping them together is precisely what allows Docker to set up shared networking and coordinated startup automatically.

By name, over an automatically created shared private network, as explained in Chapter 5 — there’s no need to look up or hard-code numeric network addresses.

No — as the warning in Chapter 6 explains, a dependency only controls start order, not full readiness, which is why many real services add their own retry or readiness logic.

Technically yes, but it only makes sense for services designed to run safely as duplicates, such as stateless web servers — as covered in Chapter 7, a single database service is usually kept at one container.

If storage was properly defined for that service, as discussed in Chapter 9, its data lives in a persistent volume separate from the container itself, so replacing the container doesn’t lose the data.

Defining a service in Docker means writing down exactly how one piece of your application should run — its image, its network needs, its dependencies, its restart behavior, and its storage — so that piece can be created, connected, scaled, and recovered predictably every single time. Breaking an application into multiple, clearly defined services rather than one giant container is what makes modern applications resilient, independently scalable, and genuinely understandable by an entire team, not just the person who originally set it up.