MicroLab vs Docker Compose vs local Kubernetes
All three come up in the same conversation —“how do we set up the local environment?”— and they solve different problems. This page says which is which, without pretending the other two are wrong: most teams end up using more than one, and MicroLab in fact leans on Docker for infrastructure.
<h2>In one sentence</h2>
<ul>
<li>
<strong>Docker Compose</strong> declares a set of containers and brings them up
together. It is the standard tool for infrastructure, and for systems that run
entirely in containers.
</li>
<li>
<strong>Local Kubernetes</strong> (Kind, minikube, k3d) puts a Kubernetes
cluster on your machine. Its reason to exist is resembling production: testing
manifests, Helm charts, operators and policies.
</li>
<li>
<strong>MicroLab</strong> is a desktop orchestrator for the daily loop: it
brings up the services of a flow and, above all, decides
<strong>where each one calls</strong> —another local service, the cloud, or a
mock— rewriting the URLs without touching the repositories.
</li>
</ul>
<h2>The table</h2>
<div class="legal-table-wrap">
<table>
<thead>
<tr>
<th>Criterion</th>
<th>Docker Compose</th>
<th>Local Kubernetes (Kind)</th>
<th>MicroLab</th>
</tr>
</thead>
<tbody>
<tr>
<th>What it is for</th>
<td>Bringing up containers declared together</td>
<td>Reproducing Kubernetes locally</td>
<td>The daily loop with several services calling each other</td>
</tr>
<tr>
<th>How the system is described</th>
<td>A <code>docker-compose.yml</code> you write</td>
<td>Manifests or charts, plus the cluster configuration</td>
<td>Autodetected from the repo (stack, ports, infrastructure, dependencies) for you to review</td>
</tr>
<tr>
<th>Where each service calls</th>
<td>Each repo's configuration, by hand</td>
<td>Cluster discovery; reaching outside is configured separately</td>
<td>Per dependency: local, cloud or mock. The engine rewrites the URL on start</td>
</tr>
<tr>
<th>Change loop</th>
<td>Rebuild the image; <code>compose watch</code> syncs or rebuilds</td>
<td>Build, load into the cluster and deploy (Tilt or Skaffold automate it)</td>
<td>The service you are touching runs natively, with hot reload</td>
</tr>
<tr>
<th>Debugging</th>
<td>Attach the debugger to the container</td>
<td>Port-forward to the pod</td>
<td>Native process: your IDE's debugger, no middlemen</td>
</tr>
<tr>
<th>Shared infrastructure</th>
<td>Its strong suit</td>
<td>Another container or operator inside the cluster</td>
<td>Managed in Docker, remapping ports when one is taken</td>
</tr>
<tr>
<th>Faking someone else's service</th>
<td>Another container with a stub server, wired by hand</td>
<td>Same, plus manifests</td>
<td>Built in: set the dependency to <code>mock</code> and define the stub</td>
</tr>
<tr>
<th>Resemblance to production</th>
<td>Medium</td>
<td>High, and that is the whole point</td>
<td>Low on purpose: it optimises the loop, not fidelity</td>
</tr>
<tr>
<th>Sharing the setup</th>
<td>The file, versioned</td>
<td>Manifests, versioned</td>
<td>The scenario exports to a self-contained, importable file</td>
</tr>
<tr>
<th>Interface</th>
<td>Command line (plus Docker Desktop's)</td>
<td>Command line</td>
<td>Window and CLI, with the same logic behind both</td>
</tr>
<tr>
<th>Licence</th>
<td>Open source</td>
<td>Open source</td>
<td>Proprietary: free for personal use, paid for use inside an organisation</td>
</tr>
<tr>
<th>Requirements</th>
<td>A Docker engine</td>
<td>Docker and a fair amount of memory</td>
<td>Windows or Linux, and a Docker engine for the infrastructure</td>
</tr>
</tbody>
</table>
</div>
<h2>Stick with Docker Compose if…</h2>
<ul>
<li>
What you need is the <strong>infrastructure</strong>: databases, queues, caches.
Nothing beats it there, and MicroLab does not replace it — in fact it
<strong>reads your <code>docker-compose.yml</code></strong> to know what you have
declared, and never writes it.
</li>
<li>
Your system is two or three stable services you do not touch daily. Bringing
them all up in containers and forgetting about them is simpler than anything else.
</li>
<li>
You need it to work the same on any machine and in CI, with one tool and
nothing else to install.
</li>
</ul>
<h2>Stick with local Kubernetes if…</h2>
<ul>
<li>
What you are developing <strong>is</strong> Kubernetes: manifests, charts,
operators, network policies. Testing them outside a cluster proves nothing.
</li>
<li>
You need to reproduce behaviour that only shows up in the cluster —the service
mesh, an ingress, resource limits—.
</li>
<li>
You already have Tilt or Skaffold set up and the build loop does not hurt.
</li>
</ul>
<h2>Take MicroLab if…</h2>
<ul>
<li>
The flow you are testing goes through <strong>several services</strong>, and each
one calls others you do not always want to bring up.
</li>
<li>
You often change <strong>where a dependency points</strong> —today at the shared
environment, tomorrow at the colleague who has it running, the day after at a
mock because there is no VPN— and you are tired of editing configuration in
repositories that are not yours.
</li>
<li>
You want to <strong>change something and see the effect now</strong>: the service
you are working on running natively with hot reload, and the rest in containers
in the background.
</li>
<li>
Everyone who joins the team loses their first day to a <code>LOCAL_SETUP.md</code>
nobody maintains.
</li>
</ul>
<h2>Where MicroLab falls short</h2>
<p>A comparison that only says good things about whoever wrote it is worth nothing.</p>
<ul>
<li>
<strong>It does not resemble production</strong>, and it does not try to. If your
problem is something that only fails in the cluster, this will not reproduce it.
</li>
<li>
<strong>It does not speak Kubernetes.</strong> It reads no manifests or charts,
and there are no plans to.
</li>
<li>
<strong>Windows and Linux.</strong> The macOS installer will follow.
</li>
<li>
<strong>It is in beta</strong>, and it shows: it changes often.
</li>
<li>
<strong>It is not open source</strong>, and using it at work requires a paid
licence. Compose and Kind are free for any use; this is a product, and that
should be said before you run into it.
</li>
<li>
<strong>Every service has to be described once.</strong> Almost everything is
autodetected, but that first review is work you would not have with a
<code>compose</code> file that already exists.
</li>
</ul>
<h2>What usually ends up happening</h2>
<p>
All three coexist without conflict: <code>compose</code> for the shared
infrastructure —which MicroLab reads and manages—, local Kubernetes for what
really is Kubernetes and for CI, and MicroLab for the stretch where you are
changing code and need the whole flow to answer without assembling it by hand
every time.
</p>
<p>
<a class="btn btn-primary btn-lg" href="/#download">Download MicroLab</a>
</p>
<p class="doc-meta">
Free for personal use · Windows and Linux · For use inside an organisation, see
<a href="/en/pricing">Pricing</a> and the <a href="/terms">terms</a>.
</p>