When You Should Not Run Kubernetes, and What a Single Docker Compose Host Really Costs You

Jachin Ocacio — Thu, 06 Aug 2026 08:17:33 +0000

Do not run Kubernetes for a client project that fits on one server, has no autoscaling requirement, and is maintained by fewer than three people who touch infrastructure. A single Docker Compose host running behind a reverse proxy handles the majority of small agency workloads, and it costs you exactly two things: minutes of downtime during reboots, and a manual path back from hardware failure. Kubernetes does not remove those costs, it converts them into a control plane you now have to keep alive. Pick the failure mode you can actually staff.

TL;DR by reader profile:

Agency running 12 client sites on one provider (WordPress, Node APIs, a few static builds): one Compose host per client tier, because per client blast radius matters more to you than scheduling, and your real risk is a botched deploy, not capacity.
Two person team with one revenue critical app (SaaS, single Postgres, 24/7 traffic): Compose plus a warm standby and tested restores, because a second machine you can promote beats a cluster nobody on the team can debug at 3am.
Team of six with a genuine multi service platform (8 or more services, several deploys a day): Kubernetes starts paying for itself here, because rolling deploys, health gating and per service resource limits stop being manual work.
Contractor handing infrastructure back to the client at the end of the engagement: Compose, because a docker-compose.yml plus a README is a deliverable the client can actually run, and a cluster is a dependency on you.
Anyone under a contractual uptime commitment with penalties (SLA with credits attached): you need redundancy of some kind, and that is the one case where the orchestration question becomes a real engineering decision rather than a preference.
Solo developer hosting side projects and one paying client: Compose on a single host, because every hour spent on cluster maintenance is an hour not billed.

The central tradeoff: Kubernetes buys you automatic recovery and rolling deploys at the price of a permanent operational surface you must keep patched, while Compose buys you a system one person can hold in their head at the price of doing recovery yourself.

When should you not run Kubernetes?

When should you not run Kubernetes?

Skip Kubernetes when the cluster would exist to solve a problem you do not have yet. Four conditions, and if three of them describe your project, stop.

Your workload fits on one machine: the whole stack, application, database, cache and reverse proxy, runs inside the RAM and CPU of a single server you can afford. If you are not resource constrained, the scheduler has nothing to schedule.

Traffic is predictable: you know roughly what next Tuesday looks like because it looks like last Tuesday. Horizontal Pod Autoscaler is worth real money when load swings by an order of magnitude within an hour. It is worth nothing when your peak is 3x your trough and both fit on the same box.

Nobody on the team owns infrastructure full time: Kubernetes is a system that needs a person. Version skew between control plane and nodes, CNI upgrades, cert rotation, ingress controller changes and deprecated API versions all arrive whether or not anyone is assigned to them.

The client will eventually own this: you are building something you hand over. A cluster is a hiring requirement disguised as a deployment target.

Condition	Points to Compose	Points to Kubernetes
Capacity	Everything fits on one host	You are already sharding across machines
Traffic shape	Predictable, within 3x daily swing	Spiky, unpredictable, event driven
Team	Under 3 people touching infra	A named platform owner or team
Deploy frequency	A few times a week	Several times a day across services
Handover	Client inherits the stack	You operate it indefinitely
Uptime terms	Best effort, informal	Contractual SLA with penalties

The inverse is also true, and worth saying plainly so this does not read as a hit piece. If you run 8 or more services that deploy independently, if two teams need to ship without coordinating, or if your uptime commitment survives a single machine failing, Kubernetes is the correct answer and Compose will hurt you.

Immich vs Google Photos: Why Self-Hosting Your Photo Library Wins in 2026

Jachin Ocacio — Thu, 06 Aug 2026 06:31:57 +0000

Immich is the better choice if you own a machine that stays powered on and you care where your photos live. It gives you the parts of Google Photos people actually use every day, mobile auto backup, face grouping, map view, albums and shared links, without a storage meter that raises your bill as your library grows. Google Photos still wins on zero maintenance and on search that understands a sentence. If you are willing to spend one evening on setup and roughly an hour a quarter on updates, Immich replaces it.

TL;DR by reader profile:

Family archivist with 15 years of photos (Marta, two phones, one shared library): move to Immich on a small always on box, because a growing archive is exactly the case where a per gigabyte subscription compounds against you forever.
Photographer shooting RAW every weekend (Tomas, 40 megapixel bodies): Immich, because RAW files eat cloud tiers fast and you already keep a local working copy that you can point the server at.
Non technical user with one phone and no home server (Elena, iPhone, no NAS): stay on Google Photos for now, because Immich needs someone to own updates, backups and remote access, and that someone would be you.
Privacy sensitive professional handling client images (lawyer, therapist, journalist): Immich on hardware you control, because the legal question is not whether the provider is trustworthy but who can be compelled to hand over the data.
Homelab owner already running Docker (Sam, existing NAS and reverse proxy): Immich, because the marginal cost is one compose stack on infrastructure you maintain anyway.
Small team or studio sharing a shoot library (five people, one archive): Immich with per user accounts and shared albums, because Google Photos was built for one person and gets awkward the moment several people need write access.

The central tradeoff: Google Photos sells you freedom from maintenance and pays for it with a recurring bill and a library you do not control, while Immich hands you control and a one time hardware cost and charges you in setup time, backup discipline and the responsibility for your own uptime.

What is Immich, and can it really replace Google Photos?

What is Immich, and can it really replace Google Photos?

Immich is an open source, self-hosted photo and video backup server. You install it on a machine you own, install the Immich app on your phone, and it uploads new photos in the background the way Google Photos does. It is licensed under AGPL-3.0, developed in the open on GitHub, and released on a fast cadence with frequent tagged versions. It is not a photo viewer bolted onto a file share. It is a full stack with its own database, machine learning container and mobile clients for Android and iOS.

The honest answer on replacement: yes for the daily loop, partially for search.

The daily loop is backup, browse, album, share. Immich covers all four. You get automatic background upload, a timeline grouped by date, albums, shared albums with other users on your server, public share links with optional passwords and expiry, a map view built from EXIF GPS data, face grouping into named people, and duplicate detection. Multi user support is built in, so each family member gets their own library on the same server.

Where it differs is the part Google spent a decade on: semantic search quality and the automatic memories and collages that surface old photos without you asking.

Capability	Google Photos	Immich
Automatic phone backup	Yes, first party OS integration	Yes, background service in the app
Face grouping and named people	Yes	Yes, runs locally on your server
Natural language search	Yes, strong	Yes, CLIP based, weaker on complex phrasing
Storage limit	Bound to your Google One tier	Bound to your disk
Who holds the data	Google	You
Maintenance owner	Google	You

Treat Immich as a replacement for the product, not a clone of the company. You give up an army of engineers tuning search ranking. You gain a library that cannot be reindexed, repriced or closed without your consent.

DEV Community: Jachin Ocacio

When You Should Not Run Kubernetes, and What a Single Docker Compose Host Really Costs You

Table of contents

When should you not run Kubernetes?

Immich vs Google Photos: Why Self-Hosting Your Photo Library Wins in 2026

Table of contents

What is Immich, and can it really replace Google Photos?