My video-call service —Meet, a self-hosted Jitsi— doesn’t live on some paid server out there. It runs on the Mac mini at home, inside four Docker containers orchestrated with docker compose: the web frontend, the media bridge (JVB), the orchestrator (Jicofo) and the XMPP server (Prosody). And all of that is brought up by OrbStack, which on a Mac is the most convenient and lightweight way to run Linux containers.

It works great. So well that this very week I updated OrbStack, the four containers restarted on their own, and I didn’t have to touch a thing. So why would I even consider replacing it?

The temptation: containers without Docker, made by Apple #

For about a year now, Apple has shipped its own native container system in macOS: the Containerization framework and the container tool. It’s open source, written in Swift, and tuned to the bone for Apple silicon. The idea is seductive: run Linux containers without Docker in the middle, without a heavy virtual machine running all day, with native system integration. For a machine that doubles as my server for everything, removing a middle layer always sounds good.

So the question was inevitable: could I retire OrbStack and move my Jitsi to Apple’s containers?

The answer, today, is not yet. And I find it more interesting to explain why than to pretend it’s done.

The two walls #

My Meet isn’t a single container: it’s four pieces that have to talk to each other and reach the internet in a very particular way. That’s where I hit a wall.

1. There’s no native compose. Apple’s tool currently works one container at a time. But my Jitsi is defined in a single docker-compose.yml file describing the four services, their variables, their internal network and who depends on whom. Without a native equivalent to compose, migrating would mean rewriting that whole orchestration by hand with scripts, or leaning on third-party projects that are still very green. For a service I actually use, swapping something that works for something handmade and fragile isn’t worth it.

2. Video runs over UDP, and that was the weak spot. Jitsi’s media bridge needs to expose a UDP port to the outside world to carry audio and video. And port forwarding —UDP in particular— was exactly the most unstable part of Apple’s tool, with reports of “accepts the connection but doesn’t forward it”. The one thing my Meet can’t afford.

What changed this June #

At this year’s WWDC, Apple introduced macOS 27 Golden Gate. It brings quite a bit: a rebuilt Siri, design changes, a search reconstructed from the ground up, more parental controls, performance improvements… But, for what concerns me here, don’t get confused: none of it touches containers. Updating to the new version, on its own, changes nothing in this story.

What did move was the developer side, off the main stage. On one hand, the container tool reached version 1.0. And there’s a half-good piece of news there:

• UDP can now be published. They added TCP and UDP port forwarding. So wall number two has started to fall, with an asterisk: the capability existing doesn’t mean it’s reliable in production, and I’d have to test that on a bench before trusting it.
• compose still doesn’t exist. Wall number one, the one that actually blocks me, is still standing. It’s the limit everyone points to.

And there was one more thing, which got me excited at first: Apple introduced Container Machine, with its own session and all. But once you look at what it is, it’s not what my Jitsi needs. It’s a persistent Linux environment in the style of Windows’ WSL: a lightweight virtual machine with its own systemd, meant for developing on Linux from the Mac —you edit on the Mac, build and test on Linux with no file syncing—, not a system for orchestrating several containers in production. I could put my Jitsi inside one of those machines, but that would be redoing, with more steps, exactly what OrbStack already gives me. It doesn’t unblock anything.

So I’ve gone from two walls to one and a half. Progress, but the decisive one —orchestrating several containers— hasn’t fallen.

When I’ll make the jump #

It’s not a definitive “no”, it’s a “not yet”, and I’m clear on what I’m waiting for to reopen this:

• A native, stable way to orchestrate several containers (an Apple compose, or a third party that earns my trust).
• UDP forwarding proving itself solid, not just possible.

In the meantime, the sensible thing is not to touch what works. OrbStack gives me compose and reliable UDP, which is exactly what my Jitsi demands. What I will do, without rushing, is set up a separate experiment —a harmless container, without touching Meet— to get a feel for Apple’s tool and be ready the day both walls fall for good.

Something working isn’t an excuse to stop watching what’s coming next. But it isn’t a reason to change it ahead of time either.