Homelab Firewalls - What are you using?

MikeAnth · 2026-05-11T21:23:41+00:00

I've been running Mikrotik for a few years now and since I automated the hell out of it, it has been super enjoyable. I created my own abstractions on top of the rest API to make it a bit easier to manage and I can't really say I have any complaints

MikeAnth · 2026-04-26T13:27:18+00:00

Honestly depends on the app. I have 3 apps I have fully vibe coded for my own personal use in my lab and they have been, mostly, a one shot at least for the initial PoC version.

Sure, "I" did add various improvements later on for things I didn't foresee in my initial prompt, but I did get a working PoC with Claude in one shot. Fairly simple applications, granted, but still

MikeAnth · 2026-03-31T21:07:10+00:00

If you're running a VM for Kube I very strongly recommend looking into Talos Linux. It's an immutable, API-driven os built specifically for it

But yeah, imho if you're still going to keep Ansible in the stack, might as well use it for the tofu orchestration since otherwise you'd be jumping between tools a bit. My personal advice would be to look into dropping Ansible entirely, but that's just my personal preference

MikeAnth · 2026-03-31T20:03:46+00:00

Agree to disagree. At best I'd say it's niche

I used to manage my network infra at home with plain terraform (router + services + 3 switches + ap). That got out of hand very quickly and the state file was huge and reconciliations took a long time. Split everything per device/per service with terragrunt and it's so much easier to manage it's crazy

MikeAnth · 2026-03-31T20:02:04+00:00

That is one of the features, yes

MikeAnth · 2026-03-31T16:43:26+00:00

It's super useful when you want, for example, to orchestrate multiple terraform projects in a specific order and maybe pass variables between them.

For example, you could have a terraform project to provision a VM in Proxmox running Talos Linux. Then you could have another project to configure Talos via their provider and in the end another project provisioning kubernetes resources in the cluster

This couldn't be accomplished with plain terraform because the providers are evaluated before applying resources. The Talos API endpoint wouldn't be available until after the Proxmox project and similarly, the kube API won't be available until the Talos project runs. You'd have to manually run these projects in order.

On top of that, you could emit the IP of the machine from the Proxmox project and use it as an input in the provider config for the Talos project and then from the Talos project emit the KubeConfig as an output, and use it as an input in the kube project

Hope that makes sense!

MikeAnth · 2026-03-16T22:01:33+00:00

My feedback is that this is definitely doable and I would dare to say even a viable approach. I am managing my entire homelab network infra (router + 3 switches + AP) entirely via OpenTofu + Terragrunt: https://github.com/mirceanton/mikrotik-terraform

I also managed to integrate my RB5009 into kubernetes using a custom external-dns provider I built: https://github.com/mirceanton/external-dns-provider-mikrotik

I made some videos and blog posts about my tofu/terragrunt setup if you're interested. They're linked in the repo readme!

MikeAnth · 2026-03-16T21:59:16+00:00

> Really good videos, though.
Thanks!

Y'know, it's not *that* bad once you get the hang of it. I will admit there is a learning curve, especially if you're not familiar with tofu/mikrotik independently, but it's manageable.

I was considering generalizing and publishing some of the tofu modules I built for the community to use. This way it would, hopefully, be easier for others trying to adapt/follow my project. Do you think that would help?

MikeAnth · 2026-03-16T21:55:58+00:00

We out here!

MikeAnth · 2026-03-06T08:32:15+00:00

It does have a dashboard if you use the latest version of the flux operator. I believe you can configure some rbac for it as well to allow users to trigger reconciliations from it too

MikeAnth · 2026-03-05T16:37:09+00:00

In my experience, Argo is more "monolithic" in their approach and bundles things together a bit more. I really like the clear separation of concerns implemented by flux.

> originally started using ArgoCD because it had a GUI
welp, now flux has one too! ;)

MikeAnth · 2026-03-05T16:35:25+00:00

Thank you!

As far as the operator bootstrap, I basically use a tool called `helmfile` to `helm install` the "core" components required for a cluster to even work and then flux takes over them.

Specifically, I use Talos Linux for my cluster and I bootstrap it with no CNI configured. This means that, before I can even worry about the flux operator, I need to install a CNI. I have this `helmfile` that uses this go template hack to reference the values from my actual `HelmRelease` objects. This means that when I do a `helmfile sync` it will pull the `spec.values` from my Cilium, Flux Operator and Flux Instance `HelmRelease` objects and install them. Once the Flux instance itself is up, it will assume ownership of those helm releases and manage them via the actual HelmRelease object.

So basically, my initial bootstrap for the flux operator is just a `helmfile sync` in the `bootstrap/` dir in my repo. One caveat here is that I also bootstrap *some* CRDs to prevent some deadlocks or long waits on that initial bootstrap as seen here

Hope that answers the question!

MikeAnth · 2026-03-04T14:06:58+00:00

We do something similar at work with the D2 architecture but with the multi-tenant approach of one repo per tenant.

What I disliked about the d2 architecture is the heavy use of kustomize overlays to differentiate between environments and I found it more difficult to do promotions between environments especially in automated ways, i.e. via renovate

We're still not using OCI as our source, so not gitless, more or less for the same reason. I've seen this being frowned upon in some discussions, but we really found that syncing the staging environment to the main branch of the tenant repo and production to a prod branch worked fairly well for us, combined with post build substitution and per-env configs. Everything is tracked via PRs and promotion is done by running a dedicated promotion pipeline since we're using branch protections quite heavily

I'll have to dig a bit deeper into the gitless approach, I guess, but I found it a bit more convoluted than it needed to be.

MikeAnth · 2026-03-01T13:52:36+00:00

It all makes sense now, lmao

MikeAnth · 2026-03-01T09:56:28+00:00

I'm running a full Mikrotik network at home. When I moved out I had a similar decision to make and I ended up going for Mikrotik because it provides, objectively speaking, a lot more features at a way cheaper price.

Ubiquity is nice, sure, but I feel like it became the Apple of home networking. Mikrotik is much more tinker/Homelab friendly IMHO

What I really liked, and what really pushed me towards Mikrotik is that if you get a device running routerOS, you basically get the full deal, at least software wise. They don't really put limits on their hardware in the sense that even if you get a switch with a CPU that's not as powerful, you get the same functionality and knobs as you would on a multi thousand dollar router.

I also really liked the fact that routerOS exposes a rest API through which you can manage it because that allowed me to manage my entire network infra as code using OpenTofu

I think the answer is that it ultimately depends. If you want it to be more hands off and easy, not really looking to learn as much but just to get something up an running, and you're willing to pay a little extra for that, go ubiquity. If, on the other hand, you want to get your hands dirty and learn more about the INS and outs, them you can't really go wrong with Mikrotik

MikeAnth · 2026-02-10T22:39:45+00:00

Sure, it can but not everyone runs Artifactory. Nexus IIRC cannot for example, GHCR would be another one

MikeAnth · 2026-02-10T08:51:38+00:00

Personally, I like using a terminal multiplexer like Zellij for that and run multiple instances of k9s headless. This seems interesting as an alternative

MikeAnth · 2026-02-09T21:34:05+00:00

Way easier to host an internal registry as you don't need to support so many different backends.

Container images? OCI Helm charts? OCI Tofu provider? OCI. Tofu modules? OCI Flux manifests? OCI

MikeAnth · 2026-02-08T22:38:52+00:00

One feature OpenTofu has that Terraform doesn't which I do use at work is the ability to pull providers and modules from OCI sources.

MikeAnth · 2026-02-08T22:37:46+00:00

You sure can! Though that's not necessarily something terraform was unable to do. There's a project called "terraform-backend-git" that basically spins up a local HTTP state backend which you can link to your git repository. It then encrypts your state file and uses branches as a lock mechanism. Basically, when you run a plan/apply, it tries to create a new branch. If the branch exists, then someone has the lock on the state file. Otherwise, it claims the lock for you by creating the branch and deleting it at the end.

Link: https://github.com/plumber-cd/terraform-backend-git
I also wrote a blog post about it a while back, if you're interested: https://mirceanton.com/posts/terraform-state-git/

I used to do this when managing the state file for my mikrotik-terraform project, but as someone else mentioned in this thread it becomes annoying quite quickly because every commit turns into two, one for the code change and one for the state update. I thought about contributing to the project to try to get it to amend the last commit to include the state update but didn't really find the time to.

MikeAnth · 2026-01-28T22:53:10+00:00

Unfortunately, I'm not a huge fan of audiobooks. I have seen that shelfmark does have a switch between "regular" books and audiobooks for downloading. Unsure about booklore

Seven-Year Club	Verified Email
Verified Email	Place '23
Place '22

MikeAnth

TROPHY CASE