K3s vs Docker: What I Learned Choosing Between Them for My Home Server

I run a handful of services on a single home server and recently had to actually decide between sticking with Docker Compose or moving to K3s for orchestration. This post is what I found out comparing the two, where each one makes sense, and which one I'd actually pick depending on the situation.

They're Not Really Competing With Each Other

Docker and K3s solve different layers of the same general problem, which is part of why comparing them gets confusing. Docker is a container runtime and packaging tool. It builds images, runs containers, and with Docker Compose it can coordinate a handful of containers on one machine. K3s is a certified Kubernetes distribution. It orchestrates containers across one or more nodes, and it still needs a container runtime underneath it, usually containerd, to actually run anything.

For a single self-hosted server though, this distinction gets blurry fast. Docker Compose and a single-node K3s cluster end up solving the exact same real problem: running a stack of services reliably on one machine. That's the comparison that actually matters for most people, so that's what I'm focusing on here.

Where Docker Holds Up

Docker's biggest advantage is how little it asks of you. Install it, write a docker-compose.yml, and you're running something in minutes. No control plane, no scheduler, just a runtime doing what you tell it. For a single server with a dozen or so services, this is genuinely hard to beat.

It starts to strain once a second machine enters the picture. Docker Compose has no real concept of a cluster, it just manages containers on whatever host it's running on. Docker Swarm technically adds multi-node support but it hasn't seen much investment in years, so most people skip it and go straight to Kubernetes if they actually need that.

Docker makes sense when:

You're on a single server: no cluster needed if there's only one machine

Your stack is small to moderate: manageable in one compose file

You want minimal overhead: no control plane running in the background

Where K3s Holds Up

K3s exists because full Kubernetes is too heavy for a lot of real setups. It was built specifically for edge and resource-constrained environments, and it shows. It packages the API server, scheduler, controller manager, and by default a SQLite datastore into one small binary, with a much smaller memory footprint than standard Kubernetes. That makes it realistic to run on a Raspberry Pi or a few small VPS instances.

What you get for that footprint is real Kubernetes. Declarative deployments, self-healing when a pod crashes, rolling updates, and the whole Kubernetes ecosystem works with it the same as a full cluster would.
The cost is complexity. Even K3s brings YAML manifests, namespaces, and services into the picture, which is more conceptual overhead than a compose file. There's a control plane running even on a single-node setup, using CPU and memory just to exist.

K3s makes sense when:

You have multiple nodes: even two or three small machines benefit from real scheduling

You want self-healing without scripting it yourself: a crashed pod gets rescheduled automatically

You're running at the edge: IoT, remote sites, places where resources are genuinely limited

You want to learn real Kubernetes patterns: on hardware that would choke on full k8s

What I Actually Decided

For my setup, which is one server running a dozen or so services, Docker Compose still wins. It's less to learn, less to maintain, and there's less that can quietly go wrong overnight. I know people running 50+ containers this way for years without hitting a real ceiling.

The calculation changes the moment a second machine shows up, or the moment I'd rather have a crashed container restart itself than SSH in and fix it manually. That's when K3s starts earning its complexity instead of just adding to it.

There's also a case I didn't expect going in: if the goal is learning Kubernetes because that's what I'll actually be using at work, running K3s on a single node is worth it even without a second machine. In that case I'm optimizing for the learning, not the infrastructure.

Wrapping Up

I ended up sticking with Docker Compose for now, but setting up K3s for a few days to actually compare them was useful. Docker stays out of your way until you genuinely need orchestration. K3s gives you real Kubernetes behavior for a fraction of the resource cost of the full thing, but you pay for it with a heavier mental model.

If you're not sure which one you need, that's probably a sign Docker Compose is still the right call for now. You'll know you've outgrown it when the manual restarts and one-server limits start actually costing you time.

Comments

Post a Comment

Popular posts from this blog

Building a Local RAG System with Ollama and Gemma: A Complete Guide - Part 1

Image
Building a Local RAG System with Ollama and Gemma: A Complete Guide Retrieval-Augmented Generation (RAG) has revolutionized how we interact with large language models by combining the power of information retrieval with text generation. In this comprehensive guide, we’ll walk through creating a complete RAG system that runs entirely on your local machine using Ollama and the Gemma 2B model. Why Build a Local RAG System? Before diving into the implementation, let’s understand why building a local RAG system is beneficial: Data Privacy : Your sensitive documents never leave your machine Cost Efficiency : No API costs or usage limits Offline Capability : Works without internet connectivity Customization : Full control over the model and parameters Scalability : Process large document collections without external constraints What is RAG? RAG (Retrieval-Augmented Generation) combines two key components: Retrieval System : Searches for relevant...
Read more

Building a Local RAG System with Ollama and Gemma: A Complete Guide - Part 2

Image
Building a Local RAG System with Chat Memory Building a Local RAG System with Chat Memory Using Redis This is a continuation of our comprehensive guide on building a local RAG system with Ollama and Gemma. If you haven’t read Part 1, we recommend starting there to understand the foundational concepts and basic implementation. In our previous article, we successfully built a functional RAG (Retrieval-Augmented Generation) system that could process documents and answer questions based on their content. However, our system had one significant limitation: it couldn’t remember previous conversations or maintain context across multiple interactions. Today, we’ll enhance our RAG system by adding chat memory functionality using Redis, enabling it to maintain conversation history and provide more contextual responses. This upgrade transforms our stateless question-answering system into an intelligent conversational AI that can reference previous exchanges. Why Add Ch...
Read more

Building a Local RAG System with Ollama and Gemma: A Complete Guide - Part 3

Image
Deploying Your Local RAG System with Chat Memory to Google Cloud Platform Deploying Your Local RAG System with Chat Memory to Google Cloud Platform This is the third installment in our comprehensive series on building and deploying RAG (Retrieval-Augmented Generation) systems. In Part 1 , we built a foundational RAG system using Ollama and Gemma. In Part 2 , we enhanced it with Redis-based chat memory functionality. Now, we’ll take the next crucial step: deploying our memory-enhanced RAG system to Google Cloud Platform (GCP) for production use. Moving from local development to cloud deployment opens up new possibilities for your RAG system. You’ll gain better accessibility, scalability, and the ability to serve multiple users simultaneously while maintaining the same powerful local AI capabilities we’ve built. Why Deploy to Google Cloud Platform? Before diving into the deployment process, let’s understand why GCP is an excellent choice for hosting your RAG ...
Read more