A serious production on a single machine

The first thing to say about a single-machine production is that capacity is almost never the constraint. A modest machine handles more requests than a small product will generate, and the expensive part of operating it is not CPU. It is the set of decisions that a larger platform would have made for you: what terminates transport security, what filters traffic, what is allowed to listen on a public interface, how an update is rolled back, and what happens when the disk fills at three in the morning.

Roles, not products

This paper describes a working deployment, and it names almost no products. That is a deliberate choice, and it is worth explaining before the architecture, because the explanation is itself part of the argument.

A description detailed enough to be useful to a reader is also detailed enough to be useful to someone looking for a way in. Running configurations are reconnaissance: the version of a component, the port a console listens on, the names of the services that talk to each other. None of that is secret in the sense of a password, but all of it shortens the work of an attacker who is choosing a target. A shortlist of precise facts — which appliance, which release, which management surface — is a better gift than a generic description of good practice.

So the interesting content of a deployment paper is not the inventory. It is the assignment of roles and the reasoning behind them:

Entry point

The only process that terminates transport security and accepts connections from the internet. Everything else is behind it.

Filtering layer

Inspects requests before they reach the application and holds the rules that change most often.

Application

Serves the product. It has no public address and no configuration that assumes one.

Data

Holds the state that matters and that is hardest to rebuild. It is not reachable from the entry point directly.

Management plane

Everything with operator authority: consoles, dashboards, control APIs. It is not reachable from a public interface at all.

Roles are portable. The products that fill them change every few years, and the reasoning does not. A reader who understands why the management plane is the real boundary can apply it to whatever components they happen to run, without being told which ones they are.

The shape of the edge

The architecture has one public listener and a chain behind it. The entry point terminates transport security, obtains and renews its own certificates, and forwards to a filtering layer. The filtering layer inspects the request and forwards it to the application, which runs with no published address at all.

flowchart LR
internet["Internet"] --> edge["Entry point: transport security and routing"]
edge --> filter["Filtering layer: inspection"]
filter --> app["Application: no public address"]
app --> data["Data: state that matters"]
admin["Management plane"] -.->|"not publicly reachable"| edge
admin -.->|"not publicly reachable"| filter

Two properties matter more than the components chosen. First, there is exactly one place where public traffic enters, so there is exactly one place where transport security, headers and rate limits are configured — and one place to audit. Second, the application has no published address. A mistake in how it binds does not expose it to the internet, because there is no route from the internet to it that does not pass through the filtering layer first; the mistake has to be made twice to matter.

The other property is quieter. When the entry point is configured from a file rather than from a sequence of clicks in a control panel, the configuration is reviewable, diffable and reproducible. The reason this matters for security is not tidiness: a configuration that lives in a file can be audited before it is applied and rolled back after, whereas a configuration that lives in a running process is only ever inspected after something has gone wrong.

The management plane is the real risk

Every component in the stack has a management interface: the entry point, the filtering layer, the process supervisor, the monitoring dashboard. These interfaces are more dangerous than the application because they are designed for an operator with full authority, and they are usually protected by a credential rather than by a network boundary.

The rule that has removed the most risk in my experience is simple: management interfaces are never published on a public interface; they are reachable only from inside, through the same channel that was already required to administer the machine. The consoles and the control APIs are bound to the machine itself, on ports that exist only internally. Reaching them requires the administrative key that was already required for everything else, so the management plane inherits one perimeter instead of inventing several.

Public listeners

Exactly what the service needs and nothing more. Every additional listening socket is a finding, not a convenience.

Management bindings

Internal only, reached through the administrative channel. No shared password on a management interface.

Administrative access

Key-based, no password login, no direct root login. That key is the perimeter for the management plane.

Secrets

Kept outside the images and outside the repository, with restrictive permissions. Never baked into what is deployed.

Egress

Outbound traffic is allowed but observed. A service that suddenly talks to an unknown host is a signal.

The point is not that an internal binding is unbreakable. It is that an attacker who has reached the management interface from inside has usually already compromised the machine, whereas an attacker who finds a console exposed on an arbitrary port has a much easier path in. Removing the public binding removes an entire class of opportunistic attacks, and it costs nothing.

Pin what you deploy

The most common way a stable stack becomes unstable is an update nobody chose. A moving tag is a promise that a future build will be different, and the difference will arrive at the least convenient moment.

The discipline is unglamorous: pin artifacts to a specific version, read the changelog before moving the pin, and move one component at a time. A patch update becomes a two-line change — a new pin and a restart — preceded by reading the release notes and followed by checking the management console and the public path. The same pattern applies to every component in the chain.

An update ritual that fits on an index card. The point is not the steps; it is that the steps are the same every time.

Pinning is also what makes a rollback possible. If the previous version is a reference that still exists, rolling back is the same operation as rolling forward. If the previous state was a moving tag, rolling back means guessing.

State: what is reproducible and what is precious

A one-machine stack has two kinds of state, and conflating them is how backups fail. The first kind is reproducible: deployment definitions, edge configuration, application artifacts. All of it belongs in version control, and a rebuild should be a scripted exercise rather than an archaeology project. The second kind is precious: databases, uploads, filtering rules, the certificate store, environment secrets. All of it needs a backup that has been restored at least once.

The practical split is the same everywhere: configuration lives in version control and is deployed by pulling and restarting; data lives in managed volumes and is backed up on a schedule with retention; secrets live in a file outside the repository, backed up encrypted and restored by the same script. The certificate store is the exception that is easiest to forget — automatic renewal is not a backup strategy if the renewal fails while you are away.

Observability without a platform

A single machine does not need a metrics platform, but it needs three signals. It needs to know that the public endpoint answers, that certificates are not about to expire, and that the disk is not filling. Those three cover most of the incidents that take a small service down, and they are cheap: an external availability check, an expiry check and a disk threshold alert.

Logs are the fourth signal, and the one most often left on the machine until it matters. A rotation policy and a retention window are enough; shipping everything to a central store is a larger project that can wait. What cannot wait is being able to answer, after an incident, which request hit which service and what the filtering layer did with it.

The limits, stated plainly

One machine has no high availability. A kernel update, a disk failure or a provider maintenance window is an outage, and the only mitigation is to make the outage short and predictable. A rebuild-from-source-control script with a tested restore is the honest answer; a second machine that shares the same disk is not.

The second limit is blast radius. Every service on the machine shares the kernel and the network namespace of the host. Containers isolate processes, not the machine, so a compromised container is closer to a compromised host than a marketing page suggests. That is why the management plane matters so much: the boundary between “one service is broken” and “everything is theirs” is the management interface.

The third limit is attention. A single machine is easy to run and easy to forget. The update ritual, the expiry check and the restore rehearsal all happen only if they are scheduled, which is why they belong in a calendar rather than in good intentions.

One public entry point

Transport security terminates in one place; everything else is internal. Audit the listening sockets, not the documentation.

No published application address

The application is reachable only through the entry point and the filtering layer.

Management plane not publicly reachable

Every console and control API confined to the machine, reached through the administrative channel.

Pinned artifacts

Specific versions in an override, with the reason for the pin recorded.

Tested restore

A restore that has actually been run, with a measured duration.

Three signals

Availability, certificate expiry, disk. Everything else is a bonus.

Scaling out: when the edge becomes dedicated equipment

One machine is a starting point, not a ceiling. The same shape scales, and the interesting part is that scaling it is not mainly about running more application servers. It is about moving each role onto dedicated equipment once the workload, the compliance regime or the threat model justifies it — and about what that separation makes possible.

The first thing to give dedicated hardware is the entry point. A dedicated router or gateway with the public address means the machines behind it are no longer the first thing the internet touches. It can perform the coarse work — dropping traffic that has no reason to arrive, rate-limiting floods, holding the address independent of any single server — before a request ever reaches a host that runs the product. The point is not brand or model; the point is that the public face of the system becomes a device whose only job is to be a public face.

The second is the filtering layer. On a single machine, inspection runs as software competing for the same resources as the application, and a heavy rule set becomes a stability risk. Moving it to a dedicated appliance — hardware built for inspection, sized for peak traffic rather than average — separates two concerns that were never really the same problem. The appliance can be updated and even restarted during a maintenance window without touching the application, and the application can be redeployed without renegotiating the security posture. Inspection also becomes inspectable: a device whose whole purpose is filtering is a device whose output you can watch and tune.

The third separation is between the data plane and the management plane across hosts. Once there is more than one machine, the rule that made a single machine safe — management interfaces not publicly reachable — has to be enforced between machines, not just inside one. Management traffic belongs on a separate network or a separate interface, so that a compromise of an application host does not hand over the console of the appliance that protects it. The same principle simply grows a dimension.

What the larger shape buys is not only capacity. It buys blast radius reduction: the compromise of one application host is no longer adjacent to the compromise of the edge. It buys maintenance independence: the filtering layer can be worked on while the application runs, and the reverse. And it buys headroom in the threat model: a dedicated appliance can be kept current and monitored at a level that would be overkill, and unaffordable attention, on the machine that also runs the product.

What it costs is everything that made the single machine attractive. There is more to configure, more to keep in sync, more names to resolve and more that can be misconfigured in a way nobody notices until it fails. The disciplines do not disappear when the equipment arrives; they multiply. Pinning, tested restores and the update ritual apply to each device now, and the management-plane rule has to hold on every hop instead of one.

The honest version of the scaling story is this: move a role onto dedicated equipment when the role has become a distinct problem with its own update cycle, its own failure modes and its own reason to be watched. The entry point qualifies almost immediately, because being the public face is a full-time job. Inspection qualifies as soon as its rule set starts to compete with the application for stability. Splitting roles before that just moves the complexity around without buying the separation that made the split worthwhile.

Closing

A single machine is not a compromise you apologise for. It is an architecture with a small number of components and a large number of decisions, and the decisions are the work. The same is true of the larger shape: more equipment does not remove the decisions, it multiplies them and makes their consistency the thing that matters. The machine is replaceable. The discipline is the asset.