Photo by The Connected Narrative on Unsplash
Recently I started experimenting with Lima while rethinking how I manage development environments and small backend services.
What began as simple curiosity quickly evolved into a practical approach: using Lima VMs as disposable development environments alongside running faasd in my homelab for serverless experiments.
I'm still in the early stages of this setup, but I wanted to document the journey and the reasoning behind it.
Why I Started Exploring Lima
Like many developers, my laptop gradually accumulated development tools over time.
Different languages, frameworks, and dependencies.
Most of the time, this works fine, but occasionally you run into issues like:
- dependency conflicts
- toolchain mismatches
- leftover configuration from old projects
Technically, you can manage all of this carefully on one machine.
But I started wondering:
What if every project had its own isolated environment?
That curiosity led me to Lima.
For those unfamiliar, Lima is a tool that runs lightweight Linux virtual machines on macOS, allowing developers to work with real Linux environments without needing a full desktop VM.
It’s somewhat similar in spirit to WSL on Windows but designed specifically for macOS.
Why Bother with Isolation?
At some point, you might ask:
Why complicate things?
You could absolutely just install everything directly on your machine and manage it carefully.
But isolating environments changes the mindset.
Instead of:
One machine
Many tools
Many projects
You get something closer to:
Project A → VM A
Project B → VM B
Experimental stack → disposable VM
If something breaks, you simply destroy the VM and recreate it.
No leftover dependencies.
No mysterious configuration conflicts.
It also encourages cleaner setups because every environment starts fresh.
My Development Setup
Right now my setup looks roughly like this:
MacBook (macOS)
└─ Lima VM
└─ Development tools
Inside Lima, I install the tools required for a specific project.
If the environment becomes messy or outdated, I can simply destroy the VM and recreate it.
This approach also lets me simulate something closer to a real Linux server environment.
My Homelab Side Project: faasd
Outside of development, I run a small homelab where I host services for personal projects.
Whenever I build small applications, they usually require some kind of backend service.
Traditionally that meant adding more containers to my homelab infrastructure.
But I’ve always been fascinated with serverless platforms.
Services like AWS Lambda or Firebase Functions make it easy to deploy small pieces of code without managing full servers.
The problem is that I wanted something self-hosted.
That’s when I discovered OpenFaaS.
Discovering faasd
OpenFaaS is a powerful serverless framework, but setting it up can be fairly complex.
While exploring the ecosystem I discovered faasd, a lightweight single-node version designed for simpler deployments.
Perfect for experimentation.
Or so I thought.
My First Wrong Assumption
Because I was already familiar with Docker, I initially assumed faasd would integrate easily with my existing Docker setup.
That assumption turned out to be wrong.
faasd runs on containerd, not Docker, and this caused conflicts with my existing environment.
At this point I considered several options:
- spinning up a cloud server just for experimentation
- abandoning the idea and using AWS Lambda
- finding a way to isolate the environment
And that’s where Lima became useful again.
Separating Development and Runtime
Eventually I landed on a setup that felt much cleaner.
My development environment runs in Lima on my MacBook.
My faasd environment runs on my homelab Linux machine.
MacBook (macOS)
└─ Lima VM
└─ Development environment
Homelab Server (Linux)
└─ faasd
└─ serverless functions
Photo by Albert Stoynov on Unsplash
This separation allows me to experiment with serverless functions without polluting my main development system.
Making faasd Accessible Remotely
Once faasd was running in my homelab, I wanted to take things a step further.
I exposed the faasd gateway using Cloudflare Tunnels, which allowed me to access it remotely without opening ports on my home network.
The flow now looks something like this:
Client
↓
Cloudflare Tunnel
↓
faasd Gateway
↓
Serverless Function
This makes it possible to deploy and test functions remotely from my development environment.
Where I Am Now
Right now I’m still very much at the beginner stage of this setup.
But I now have a working environment where I can experiment with:
- Lima-based development environments
- self-hosted serverless functions
- isolated project setups
- remote function deployments
And most importantly, I can do all of this without affecting my main development machine or homelab infrastructure.
Why This Experiment Matters
For developers who enjoy experimenting with infrastructure, Lima opens an interesting possibility.
Instead of treating your laptop as one large development environment, you can treat it more like a mini cloud, where each project runs in its own isolated space.
It’s still an evolving workflow for me, but the idea of disposable development environments combined with self-hosted serverless platforms feels very powerful.
What I Want to Explore Next
Some things I want to experiment with next:
- running multiple Lima VMs for different projects
- integrating faasd with real applications
- building small APIs as serverless functions
- improving deployment workflows
This is still very much an ongoing experiment, but that's part of the fun.
If you're experimenting with Lima, homelabs, or self-hosted serverless platforms, I'd be curious to hear how you're using them.
Roadmap
Looking ahead, here’s what I plan to focus on:
- Automating Lima VM provisioning and configuration for faster setup
- Creating reusable faasd function templates for common use cases
- Exploring CI/CD pipelines that integrate with my Lima and faasd environments
- Investigating security best practices for exposing serverless functions remotely
- Documenting lessons learned and sharing guides for others interested in similar setups
This roadmap will evolve as I learn more and refine the workflow, but it provides a clear direction for the next steps.
Top comments (0)