You can rebuild srv-tramontana in fifty minutes. You can test any change before applying it, detect an intrusion, encrypt the secrets, diagnose an anomalous latency and recover a broken boot. And even so, if that machine goes down, Tramontana Bookings is down.

A disk that fails, a power supply, a network outage at the provider, a kernel that will not boot after an update, or simply scheduled maintenance on the infrastructure it lives on. In the best case, fifty minutes of interruption — and that assumes somebody is awake to launch the playbook. All the work of seven modules rests on a single machine, which is the exact definition of a single point of failure.

This lesson attacks that problem, and it does so with a warning up front: high availability is expensive, complex and, done badly, it worsens reliability rather than improving it. A system with more pieces has more ways of failing. The lesson ends with an honest analysis of whether Tramontana needs this, because the professional answer is not always yes.

1. Vocabulary: availability, nines, MTBF and MTTR
2. Vertical and horizontal scaling
3. Redundancy: active-passive and active-active
4. State is the hard problem
5. Load balancing: layers, algorithms and health checks
6. HAProxy in practice
7. High availability for the load balancer: keepalived and VRRP
8. Split-brain and quorum
9. Data replication
10. Clusters, Pacemaker and fencing
11. A design for Tramontana and the cost analysis
12. Testing failures by causing them

The field is full of terms that get used as synonyms and are not. Pinning them down saves expensive misunderstandings.

Availability is the fraction of time in which the service responds correctly. It is expressed as a percentage, and in "nines":

Reading that table slowly corrects almost everybody's intuition. 99.99% means less than a minute of downtime a week, updates, reboots for a new kernel and provider failures included. With a single server, one monthly three-minute reboot already puts you below three and a half nines. And each additional nine multiplies the cost by roughly three.

Three distinctions worth having clear:

• Reliability is the probability of running without failure over an interval. A system can be highly available and not very reliable: it fails often, but it recovers in seconds.
• Durability refers to the data: the probability of not losing it. It is independent of availability — a system can be down and have its data perfectly safe.
• MTBF (mean time between failures) and MTTR (mean time to repair) break availability down:

And that formula contains the whole lesson's strategic decision: there are two ways of raising availability. Increasing MTBF — failing less: better hardware, more testing, fewer changes — or reducing MTTR — recovering sooner. In practice, reducing MTTR is almost always cheaper and more effective, because MTBF has a physical ceiling and MTTR does not.

It is exactly what you did in 07-06 without calling it that: taking MTTR from 8 hours to 50 minutes multiplied availability without buying a single component.

And the relationship with what you already have agreed with Marta:

There is a gap there: nobody has set an availability target. And without one, you cannot decide how much to invest.

The row that matters here is the second to last. Doubling srv-tramontana's memory would make it faster and exactly as fragile. Horizontal scaling is what allows the failure of one machine not to be the failure of the service, and that is why this lesson is about horizontal scaling even though the problem is not one of capacity.

Having two machines is not the same as having redundancy: you have to decide what each one does.

The active-passive risk is always underestimated and deserves a name of its own: a passive node that is never used is a node you do not know works. It was installed eight months ago, it has not had the latest updates, it has an expired certificate or a full disk. On the day of the failure, you discover that the backup fails too. The only defence is to use it periodically: fail over deliberately every few weeks.

Here is the conceptual core of the lesson, and what separates a design that works from one that looks as though it works.

Replicating processes is easy: you start the same application on two machines and you have two. Replicating state is hard, and state lives in more places than it seems.

An inventory of Tramontana Bookings' state:

That scheduled-tasks row is the one that causes the most trouble in practice, because nobody thinks about it when duplicating a server. With two identical nodes, tramontana-backup.timer fires at 02:30 on both: two simultaneous backups to the same destination, competing for the flock — which is local to each machine and therefore protects nothing. The solution requires a distributed lock or running the tasks only on one designated node.

A stateless application is one whose instances keep nothing between requests: all the state is in the database or in a shared store. It is the requirement for active-active, and it is almost never met without development work. In Tramontana:

Honest conclusion: Tramontana is not a stateless application today. Before setting anything up, two changes to the application are needed: externalised sessions and files in shared storage. That is development work, and telling Marta before buying servers is part of the job.

A load balancer distributes requests among several servers. It operates at one of two layers:

For HTTP, layer 7 is almost always the right one: it lets you terminate TLS at a single point, route by path, retry a request that fails and make meaningful health checks.

leastconn is the most suitable for Tramontana: an availability query takes 40 ms and a billing report takes several seconds, so distributing in turns would pile the slow ones onto the same node.

This is the piece that makes the load balancer useful: without it, it would carry on sending traffic to a server that is down.

The right thing is to use both. And this is where something you have had since Module 4 fits in: health_check.sh returns 0, 1 or 2 — OK, warning, critical. That gradation is exactly what a load balancer needs, provided the application exposes an equivalent endpoint:

And the distinction almost nobody gets right: a shallow health check is worse than none. If the health endpoint only says "I am alive" without checking the database, the load balancer will carry on sending traffic to a node that cannot serve a single request. If it checks too much — a heavy query, for instance — a database problem marks every node as down and the service disappears entirely, when it could at least have served the static pages.

The balance: check the critical dependencies with a cheap operation. A SELECT 1 with a time limit, not a report.

A sticky session ties each client to one node, by cookie or by IP. It solves the problem of in-memory sessions... and creates others:

• The distribution becomes unbalanced: one node can end up with three times the load.
• When a node goes down, all of its users lose their session at once.
• It prevents draining a node for maintenance without affecting anybody.
• It masks the real problem instead of solving it.

It is an acceptable stopgap while sessions are being externalised. As a permanent solution, no.

To deploy without cutting the service, a node has to be able to leave the rotation in an orderly way: stop receiving new requests and finish the ones it already has in flight.

Repeated node by node, that is a zero-downtime deployment. And it is the answer to something left outstanding since 04-07: deploy.sh restarts the service, and that restart is a few seconds of rejected requests. With two nodes and draining, zero.

Four details in that configuration deserve an explanation:

slowstart 30s. When a node comes back after a failure, its caches are cold and its connection pools empty. Sending it a third of the traffic all at once can bring it down again, and start a cycle of outages. slowstart raises its weight gradually over 30 seconds.

rise 2 fall 3. Asymmetric on purpose: three consecutive failures are needed to take a node out (avoiding false positives from a spike) but only two successes to bring it back. Taking a node out on a single transient failure is how a load balancer causes an outage.

option redispatch with retry-on. If the chosen server fails, it retries on another. With one important nuance: retrying a POST can duplicate a booking. HAProxy only retries when the request has not been sent or the method is idempotent.

The stick-table with rate limiting. It is 06-03's fail2ban at layer 7: it counts requests per IP in 10-second windows and returns 429 when the threshold is exceeded. Complementary, not a substitute: fail2ban blocks at the network level and this one at the application level.

Nginx can do the same thing with upstream, and it is the natural option if you already have it as a reverse proxy — which is what you will set up in 08-01:

The practical difference: Nginx only does passive checks in its free version; the active ones belong to the commercial version. HAProxy has them as standard, and that is why it is preferable when balancing is the main job.

And here is the most common design error in the field, so frequent that it deserves stating on its own:

Putting a load balancer in front of two servers does not remove the single point of failure: it moves it to the load balancer.

Before, you had one machine that could go down. Now you have three, and if the one that distributes goes down, the service disappears just the same — with the aggravating factor that there are now more pieces that can fail.

The solution is VRRP (Virtual Router Redundancy Protocol): two load balancers share a floating virtual IP, the one DNS points at. One holds it; if it stops advertising, the other takes it over within seconds.

The mechanism: the node with the higher priority advertises the VIP every second. If the backup stops hearing advertisements for three intervals, it assumes the primary has gone down, assigns itself the IP and sends a gratuitous ARP so that the network switches update their tables. The failover takes between 3 and 4 seconds.

The track_script with weight -40 is what avoids the silliest failure in this architecture: without it, a node where keepalived works but HAProxy is dead cheerfully keeps the VIP, and the service is down even though the other load balancer is perfectly fine. With it, lb1's priority drops from 100 to 60, below lb2's 90, and the VIP moves.

And enable_script_security with script_user is a real security precaution: keepalived runs as root and executes those scripts; without those directives, a script with loose permissions is a privilege escalation.

The characteristic failure of any redundant system, and the one that causes the most serious data losses.

Split-brain happens when the nodes stop seeing each other but both keep running. Each concludes that the other has gone down, and both declare themselves primary:

• Two load balancers advertise the same virtual IP → unpredictable traffic, broken connections.
• Two databases accept writes → the data diverges, and reconciling it afterwards can be impossible.

The scenario that causes it is not a node going down — that is handled well — but the network between them being cut while both are still alive and serving clients. It is more frequent than it sounds: a switch that fails, a badly placed firewall rule, a momentary saturation.

The three defences:

And the conclusion to hold on to:

With two nodes there is no possible quorum. Neither can have a majority of two. That is why a serious cluster has three nodes, or two plus a witness.

This has a direct consequence for Tramontana's design: a pair of load balancers with VRRP is acceptable, because the worst case — two nodes advertising the same IP for a few seconds — is annoying but recoverable. A pair of databases with automatic failover is not: the worst case is data divergence, and it does not recover. Hence the recommendation in the next section.

PostgreSQL replicates through the write-ahead log (WAL): the primary sends its changes to one or more replicas.

And the trade-off, which has to be understood before choosing: with synchronous replication, every write waits for the round trip to the replica. On the same local network, one or two milliseconds. Between data centres, tens. And if the replica goes down, the primary blocks waiting for confirmation — unless synchronous_standby_names is configured with the right syntax, which opens the door to losing data exactly when it matters most.

For Tramontana, with an agreed RPO of 4 hours, asynchronous replication is more than enough: losing the last few seconds of transactions is well within what is tolerated.

That lag_bytes is the metric to watch: it is how much data would be lost if the primary went down now. It goes straight into the monitoring, alongside the age of the last backup from 05-08.

The professional recommendation, and it goes against intuition:

With two nodes, database failover must be manual. Without quorum, a network failure between primary and replica can promote the replica while the primary is still accepting writes, and then there are two diverging databases. Recovering from that can mean losing transactions or reconciling by hand.

Tools such as Patroni do automatic failover safely, but they require a distributed configuration store with quorum of its own (etcd or Consul), which in turn needs three nodes. In other words: automating failover safely requires at least five machines. It is an architectural decision, not a box to tick.

For /opt/tramontana/shared/uploads:

NFS has the characteristic irony: it is mounted to provide high availability and, if it is not made redundant too, it worsens reliability, because now two servers depend on a third machine.

The modern answer is the object store: it is what applications designed to scale horizontally use. It demands development work, and it is the same conclusion as the section on state.

For more complex scenarios — databases, shared filesystems, resources with dependencies — there is the Pacemaker + Corosync stack:

• Corosync: communication between nodes, cluster membership and quorum.
• Pacemaker: resource management, with dependencies and constraints.

A resource is anything the cluster manages (an IP, a service, a filesystem), and the constraints express rules: "the IP must be where the PostgreSQL primary is", "this service must start after that one".

And the concept without which none of this really works:

Fencing (or STONITH, Shoot The Other Node In The Head): before taking over the resources of a node that appears to be down, the survivor makes sure it is powered off, by cutting its power or destroying its virtual machine.

Why it is indispensable: if node A appears to be down but is in fact merely frozen or cut off, and B takes over its resources — mounts the filesystem, promotes the database, takes the IP — then when A recovers both will write to the same data. The resulting corruption can be unrecoverable.

On physical hardware it is done with IPMI, iLO or manageable power distribution units. And the rule in the field is blunt: a cluster with no fencing configured is not a reliable cluster. Many projects disable it "temporarily" because it complicates testing, and that is exactly the configuration that causes data loss on the day of the failure.

What each layer protects against, and what it does not:

The last three rows are the ones to underline for management. Redundancy does not protect against logical errors: a mistaken DELETE replicates to the replica in milliseconds. That is what the backups from 05-08 are for, and this architecture does not replace them in the slightest.

What the lesson has been promising, and what Marta has been asking for over three replies:

Cost of the complete architecture (5 machines against 1):

The cost of unavailability. The question that has to be answered first:

But that raw calculation is misleading for three reasons, and saying so is part of the analysis:

1. Bookings are not uniform. They cluster in the afternoon and at weekends. A two-hour outage at four in the morning on a Tuesday may cost nothing; the same outage on a Friday afternoon costs much more than the average.
2. A lost booking is not always lost. Many customers try again. The real cost is between 20% and 50% of the raw figure.
3. There is a reputational cost, non-linear and hard to quantify, especially if the outage coincides with a campaign.

A reasonable estimate of the annual cost of unavailability, at different targets:

The saving from going from 99.5% to 99.9% is about €2,700 a year. That has to be compared against the cost of the complete architecture — four more machines, six weeks of initial work and four hours a month indefinitely — which very probably exceeds it.

And here is the analysis almost nobody does, and which changes the recommendation:

The first step captures most of the benefit for a fraction of the cost, and this is the usual pattern in availability: the first nines are cheap and the following ones get exponentially more expensive. The reason is that most interruptions do not come from a hardware failure but from deployments, reboots and maintenance — and all of that is covered by two application nodes and connection draining, without touching the database.

Phase 1 (now): set a formal availability target with Marta. Without a target you cannot decide how much to invest. And measure it, because the current 99.5% is an estimate, not a figure.

Phase 2 (1-2 months): two application nodes and one load balancer. Externalised sessions and files in an object store, which is development work. It eliminates interruptions caused by deployment and by the failure of one node, which are the majority.

Phase 3 (assess later): a second load balancer with VRRP, and a PostgreSQL replica with manual promotion.

Phase 4 (probably never): automatic database failover. It requires quorum, which is to say five machines and a distributed store. For a company of this size, the complexity outweighs the benefit.

An untested high-availability system is not a high-availability system: it is an architecture you believe works. And the history of the field is full of cases where the backup failed on the day it was needed.

Test 4 is the most uncomfortable and the most important: it cannot be "passed" with two nodes, because without quorum split-brain is unavoidable. What you do is document the observed behaviour and the recovery procedure, so that on the day it happens nobody has to improvise.

Chaos engineering takes this further: injecting failures continuously and automatically in production, on the logic that if failures happen every day, the system is forced to tolerate them and the team is forced to know how to respond. For Tramontana it is disproportionate; the principle — cause the failures yourself, during working hours, instead of waiting for them — applies at any scale, and it fits the six-monthly rehearsal you proposed in 07-06.

• Putting in a load balancer and thinking you now have high availability. All you have done is move the single point of failure. The load balancer needs redundancy of its own.
• Configuring VRRP without track_script. A node with keepalived alive and HAProxy dead keeps the virtual IP, and the service is down with both load balancers "working".
• Automatic database failover with two nodes. Without quorum, a network partition produces two primaries and diverging data. Manual, until there are three nodes.
• Disabling fencing "temporarily". It is the configuration that causes data corruption on the day of the failure. A cluster with no fencing is not reliable.
• Shallow health checks. A /health that only says "I am alive" makes the load balancer send traffic to a node that cannot serve anything.
• Health checks that are too deep. A database failure marks every node as down, when they could have served something.
• Taking a node out on the first failure. A transient spike takes the node out, the load concentrates on the rest, and they fall in a cascade. fall 3 and slowstart.
• Forgetting that the timers run on every node. Two simultaneous backups, two purges. The flock is local and protects nothing.
• Sticky sessions as a permanent solution. They mask the real problem, unbalance the load, and when a node goes down it loses all of its sessions.
• Believing that replication replaces backups. An accidental deletion replicates in milliseconds. Redundancy protects against hardware failure, not against human error.
• NFS with no redundancy of its own to provide high availability. You add a single point of failure that two servers now depend on.
• Not testing the failures. An untested high-availability system is an architecture you believe works.
• A tip on method. Before designing anything, set the availability target and measure the current one. Without those two numbers, any investment is a hunch dressed up as architecture.

Design the /health endpoint the application should expose so that HAProxy makes good decisions. Specify what it checks, what it does not, what codes it returns and with what latency, and explain how it relates to health_check.sh.

Write the Ansible role that deploys the HAProxy and keepalived configuration on both load balancers, bearing in mind that the configuration differs between them and that applying it badly leaves the service with no IP.

Marta asks directly: "Do we need high availability?". Write the answer with the complete analysis and a clear recommendation.

Solution 1

Design of the /health endpoint:

The three states and their responses:

The relationship with health_check.sh is the conceptual part of the exercise. Both answer the same question from different sides, and that complementarity should be exploited rather than duplicating work:

The right approach is for health_check.sh to consume /health rather than reimplementing the checks:

Four design decisions that have to be justified:

1. The degraded state returns 200, not 503. It is counterintuitive and it is correct: if the file store fails, the node can carry on serving availability queries, which are most of the traffic. Taking it out of the rotation would reduce capacity and gain nothing. The header lets the monitoring detect it without the load balancer acting on it.
2. Latency bounded by design. With a 3-second interval and two nodes, that is 40 requests a minute. The target is under 50 ms, and hence the expensive checks are cached for 30 seconds.
3. No authentication, but restricted by network. It must be reachable without credentials so that HAProxy can query it, and it must not be exposed to the Internet: the detail in the JSON is useful information for an attacker. It is blocked in the frontend:

   http-request deny if { path_beg /health } !{ src 10.0.2.0/24 }
   

4. No side effects and no blocking. A /health that writes to the database or takes a lock can cause the failure it is meant to detect. The store's write check is cached and runs in the background.

And the final warning, which is the most common mistake: /health must not check dependencies that do not belong to this node. If it checked the state of the database with a heavy query, a PostgreSQL problem would take every node out at once and the service would disappear entirely, when it could at least have returned a decent error page.

Solution 2

And the play that guarantees deployment one node at a time:

The decisions that stop the service being left with no IP:

And what has to be added to the runbook: this role is tested first in the test environment with two virtual load balancers, and in production it is run with --check --diff before running for real. The virtual_router_id must be unique on the network segment: two VRRP clusters with the same ID on the same network interfere with each other, and it is a baffling failure to diagnose.

Solution 3

Does Tramontana Bookings need high availability? To: Marta Vidal · From: Systems Operations · 18 August 2026

Short answer: full high availability, no. A first step, yes, and with a very favourable cost-benefit ratio. I recommend two application servers with a load balancer, which captures most of the benefit for a fraction of the cost.

---

First, a figure we are missing. We have no agreed availability target and we do not measure it. My estimate is that we are around 99.5%, some 44 hours of downtime a year, counting reboots for updates, deployments and the occasional incident. It is an estimate, not a figure, and the first thing I propose is that we start measuring it — it costs very little and without that number any investment is a hunch.

What we have already achieved without spending anything. Availability depends on two things: how often the system fails and how long it takes to recover. In recent weeks we have drastically reduced the second: rebuilding the server completely has gone from eight hours to fifty minutes, by automating its configuration. That has already improved availability without buying a single machine, and it is the kind of improvement to exhaust before duplicating infrastructure.

What being down would cost. With around 500 bookings a month at an average of €313.70, average revenue is about €218 an hour. That number has to be qualified in three ways:

• Bookings cluster in the afternoon and at weekends. An outage in the small hours of a Tuesday may cost nothing; the same one on a Friday afternoon costs considerably more than the average.
• Many customers who find the site down try again. The real cost is probably between 20% and 50% of the raw figure.
• There is a cost to our image, non-linear and hard to quantify, especially if it coincides with a campaign.

With a prudent estimate (35%):

Availability	Downtime per year	Estimated cost
99.5% (current situation)	44 h	~€3,340
99.8%	17.5 h	~€1,330
99.9%	8.8 h	~€670

The three options, with their real cost.

	What it includes	Investment	Availability	Annual saving
A. Do nothing	The current setup	0	~99.5%	—
B. Two servers + load balancer	2 machines, 1 week of work	Low	~99.8%	~€2,000
C. The complete architecture	4 machines, 6 weeks, +4 h/month	High	~99.9%	~€2,670

The important part is the comparison between B and C: option C costs several times more than B and adds barely €670 of additional annual saving. The reason is that the first nines are cheap and the following ones get much more expensive — and, above all, that most of our interruptions do not come from hardware failures but from deployments, reboots and maintenance, and that is resolved entirely by option B.

What option B would give us exactly:

• Zero-downtime deployments. Today every deployment means a few seconds of service cut off. With two servers one is updated while the other serves, and the customer notices nothing.
• Maintenance with no window. Rebooting for a new kernel stops being a scheduled interruption.
• Tolerance of one application server failing. The system detects it in under ten seconds and stops sending it traffic on its own.
• Capacity for peaks, as a secondary benefit.

What it would NOT give us, and this has to be said clearly:

• If the database goes down, the service goes down. Promoting the replica would be manual, 5 to 15 minutes.
• If the load balancer goes down, the service goes down. That is option C.
• If the provider's infrastructure goes down, everything goes down.
• And none of this protects against an accidental deletion or data corruption: that would replicate instantly to every node. That is what the backups are for, and they would remain just as necessary.

There is a prerequisite that is not a systems matter. Tramontana Bookings currently keeps two things inside each server: the sessions of the people browsing, and the photos that get uploaded. With two servers, anybody who logged in on one would appear logged out when served by the other, and a photo uploaded to one would not be visible from the other. Before setting anything up, development work is needed — externalising the sessions and storing the files in a shared store — some three or four weeks. It is the part of the project to plan with Luis, and without it option B does not work.

And a professional warning. Redundancy adds pieces, and each piece can fail in new ways. A badly built system is less reliable than a simple one that is well maintained. That is why I do not recommend option C: the complexity it adds — replication, promotion, the risk of two servers writing incompatible data at the same time — demands a level of vigilance and testing we cannot sustain with the current headcount. A simple architecture we understand and test is worth more than a sophisticated one nobody has rehearsed.

Recommendation, in three steps.

1. This month, at zero cost: set a formal availability target — I propose 99.8% — and start measuring it. With that we will be able to decide on data rather than on estimates.
2. In two or three months: develop the two prerequisites, and deploy option B. I would start with a single load balancer, accepting that it is a single point of failure but one far less prone to going down than the complete application.
3. Review in a year, or sooner if something changes: if the booking volume grows significantly, if an outage costs us an important customer, or if we measure availability worse than estimated.

And one last thing. Quite apart from all of the above, I want to schedule a six-monthly rehearsal: causing the failures deliberately, during working hours, and checking that the recovery works. A backup system that has never been tested is a system we know nothing about, and this applies as much to the future architecture as to the rebuild procedure we already have. The first one in September.

You know what people are talking about when they talk about high availability, and with the precision the subject demands. The nines have concrete numbers — 99.99% is less than a minute of downtime a week — availability breaks down into MTBF and MTTR, and reducing MTTR is usually far cheaper than increasing MTBF: which is exactly what you did in 07-06 by taking the rebuild from eight hours to fifty minutes, without buying anything. You know that vertical scaling adds no availability, that a passive node that is never used is a node you know nothing about, and above all that state is the hard problem: sessions, uploaded files and scheduled tasks are what stops you simply duplicating a server.

You have set up a load balancer with HAProxy that distributes by leastconn, probes health every three seconds with asymmetric fall 3 and rise 2, brings nodes back with slowstart so as not to knock them over again, and allows connections to be drained so you can deploy without cutting anybody off — resolving what was left outstanding since 04-07. You have given it redundancy with keepalived and a floating virtual IP, with the track_script that avoids the silliest failure in this architecture: a load balancer with keepalived alive and HAProxy dead holding on to the IP. And you know the two concepts without which all of this is theatre: split-brain, which with two nodes cannot be avoided because no quorum is possible, and fencing, without which a cluster is not reliable however well it starts.

And you have done the analysis Marta had been asking for over three lessons, with the conclusion that is not always welcome: the complete architecture is not worth it. Two application servers with a load balancer capture most of the benefit for a fraction of the cost, because most interruptions do not come from hardware failures but from deployments and maintenance. That the professional answer to "do we need high availability?" can be "part of it, and in this order" is as important as knowing how to build it. Along with the warning that closes the matter: redundancy done badly worsens reliability, and a simple system that is understood and tested is worth more than a sophisticated one nobody has rehearsed.

That closes Module 7, and with it the most advanced part of the course. You have learned to look inside the system: the complete boot chain and how to intervene when it breaks, diagnosis with strace, perf and eBPF when the counters are not enough, and kernel tuning with the rule of not touching what you have not measured. And you have learned to multiply it: virtualisation with KVM and the test environment the course had been missing since Module 4, containers understood as what they are — isolated processes, not small machines — automation with Ansible that turned the configuration into code and the RTO into fifty minutes, and finally the redundancy that takes away srv-tramontana's status as a single point of failure.

In Module 8: Practical Projects all of that is applied to complete builds, end to end. You will set up a web server with Nginx as a reverse proxy and TLS in front of the application — and there the encryption in transit that was prepared in 06-05 and has been waiting ever since is finally closed off. You will configure a proper PostgreSQL database server, with its tuning, its backups and its replication. You will build a home media server, which is the project where you can confirm that everything you have learned applies just as well outside work. You will bring up a VPN server with WireGuard to reach the internal network without exposing anything. You will deploy a Kubernetes cluster, which is where the containers from 07-05 and orchestration come together. And you will finish with going into production: the complete checklist, the monitoring with Prometheus and Grafana that was mentioned in 05-07, and the daily operating procedure for a system that is no longer a laboratory. Update your VM's snapshot and I will see you there.