Please keep in mind I’m asking with genuine interest as I am a happy OrbStack user otherwise, (for private use).
What is the reason Orbstack needs a connection to your license server for continued operation?
I was moving and during nearly a month there was no home internet. My server was happily chugging along on wifi though, but one day I connected to it and saw a message that OrbStack couldn’t contact the license server and soon stop functioning.
This put me off a bit and made me consider whether I want to run anything I depend on using this.
As you appear to be aware per the prefix to your question, this is the nature of all subscription software... what alternative would you choose if you were the author? Requiring the personal use edition to phone home once a month probably increases the potential sale price of the business by at least one order of magnitude.
It would be more interesting to know the plans for tracking down commercial users abusing the personal license, maybe Oracle VirtualBox Extension Pack reverse IP address lookup style. The ins and outs of software license enforcement doesn't play well on HN, though I'm guessing there are few complaints about OrbStack requiring a subscription because they offer a free personal use license and the entry level commercial use license is so cheap vs. the value provided.
It's actually exciting to see a dev tool where the developers have a sustainable business model, but this usually means there will be plenty of offers to cash out.
What’s the security model for OrbStack and its containers?
Is OrbStack rootless? Where is the security boundary for the containers? (Are they sandboxed completely from the host?)
How does the virtualisation work? (I’d assume Virtualization.framework, so I can run it without Rosetta if all containers will share host architecture?)
Does it support Docker-in-Docker and Docker-out-of-Docker? (M1 and M2 Mac’s don’t have hardware for nested virtualisation so I assume this also prevents DiD with OrbStack?)
It's a shared VM and kernel, so the security boundary between containers is only as strong as typical Linux containers, and we don't really use the VM as a strong security boundary right now. The security model is similar to running Docker containers on a native Linux machine for development.
Admin privileges aren't required on the macOS side. You can optionally allow a privileged helper for some small niceties, but the VM process never runs as root.
The virtualization stack is custom, which allows for a lot of performance and stability improvements. It's not Virtualization.framework or QEMU.
Containers don't require virtualization, so Docker-in-Docker works. Not sure what you mean by Docker-out-of-Docker, but you can run Docker in OrbStack Linux machines, and you can use the managed engine from macOS.
Is there an example somewhere of how to do Docker-in-Docker with Orbstack? I have given this a try but there does not seem to be a docker.sock (or equivalent) to mount so no way to spawn containers at the “host level” from inside a container. Maybe my mental model of Orbstack is wrong here and there is no need for a mounted socket at all?
I'm not completely sure about the use case of Docker-out-of-docker (maybe CI probably) but i guess a sibling container (a CI agent maybe) have access to docker.sock, and control other sibling containers, which i guess ( haven't tried yet) is possible with current implementation of orbstack.
currently using orbstack with a devcontainer project, and in that devcontainer i'm bringing up some other nested containers via `testcontainers` via golang, so it's completely possible and is running sweetly
Well, as someone who still lives in stone age (I guess?) I always run headless Linux VM on Windows/macOS and have all my projects/files inside VM so I unfortunately don't use your Docker/Kubernetes features, and fast file sharing is a nice to have.
But, you and your team seems to really care about client virtualization on macOS, more so than Apple. So while being a niche, I sincerely hope you may consider this sometimes later.
One reason I'm still using docker desktop in my (small) company is that our production systems are using docker compose and the networking with domains does not translate 1:1 between orbstack locally and docker compose + nginx in production. Is there an easy way to solve this?
OrbStack domains can be nice but you don't have to use them. It's fully compatible with Compose, so you can just run the same commands with no changes to your setup. Did that not work for you?
I don't fully remember the issues, but I think it was somehow necessary to run all apps on port 80 inside of the containers in order to make the OrbStack domains work properly.
I do remember now. It was about container-to-container-communication: having FQDN is awesome because it helps you not to care about quirks of localhost:PORT everywhere in your code (SSL out of the box would be great, though). The problem is that, other than real world FQDN, the domain name of container A is not available inside of container B. This breaks frontend frameworks like next or nuxt which combine SSR on the first page load and do CSR on subsequent request: on the server, the API domain would be `host.docker.internal` and would need to change to `http://api.orb.local` for the client side. The docs didn't make this clear, so at first, I refactored everything to use the orbstack url, just to return back to the mix.
I have been using colima as a lightweight alternative to docker desktop and the likes of it for almost two years. Looking at the comparison provided on the orbstack website (https://docs.orbstack.dev/compare/colima) it seems to be not very accurate or at least requires some explanations/clarifications.
For instance: Low power/CPU usage is advertised as non-existent in colima. This is simply not true. Based on my perception I can't tell whether colima VM is running or not. Unlike docker desktop, especially with kubernetes on. Does not drain my battery, does not bog my CPU down unless I intentionally spin up something resource hungry.
ease of use/performance: not everyone needs GUI. colima is fine UX/devex wise with fast startup times. What does "fast network" even mean?
Linux machines/distros: not a fair comparison. colima stands for "containers on Lima" where lima is "linux machines" on macos. I.e. if you want arbitrary vms, use lima directly. colima is specifically built to spin up docker/containerd/k3s vms.
containers/kubernetes networking: this is opinionated and depends on a specific use case. In general I prefer the idea when my local kubernetes setup looks like the end production setup in the sense that I cannot mess up much with networking, access clusterip services directly from localhost because clusterip services are supposed to be accessible from inside the cluster itself, not from outside. loadbalancer IP is accessible through NodePorts anyways.
containers file access: there are plenty of ways you can access files in containers and images. But again, probably there are people who like to browse the guts of a kubernetes node in MacOS Finder. When it comes to files and networking I want to be able to re-use my toolbox used for dealing with remote kubernetes clusters and docker/containerd instances to my local ones. Creating a special case with convenient but non-standard ways to access files as if they were part of my host filesystem may be good for someone, but wrong for someone else because at times when something goes wrong this special case will work as an excuse for "works on my machine".
Please take the above as my personal experience. And I am in the herd of those who tend to keep everything as minimal and bare as possible with as much standartization/ lack of deviations across different environments as possible. Came to colima after years of minikube just because minikube's experience was no longer good with apple silicon. And there must be a very strong reason to switch to something new when what you have already is good enough.
Also, when it comes to GUI, what about Rancher Desktop?
Dev here — I've been meaning to update the Homebrew cask to be more complete on zap, but there's a good reason that all of these are needed:
- ~/.orbstack
- Docker context that points to OrbStack (for CLI)
- "source ~/.orbstack/shell/init.zsh" in .zprofile/bash_profile (to add CLI tools to PATH)
- ~/.ssh/config (for convenient SSH to OrbStack's Linux machines)
- Symlinks to CLI tools in ~/.local/bin, ~/bin, or /usr/local/bin depending on what's available (to add CLI tools to existing shells on first install — only one of these is used, not all)
- ~/OrbStack (empty dir for mounting shared files)
- /Library/PrivilegedHelperTools (to create symlinks for compatibility)
Not sure what the best solution is for people who don't use Homebrew to uninstall it. I've never liked separate uninstaller apps, and it's not possible to detect removal from /Applications when the app isn't running.
IMO documenting this (and uninstall section in GUI with link) would be enough for me. Used that and never felt neglected by devs.
And cough since we’re at with - did you consider Nixpkgs distribution?
I’m slowly moving deeper and deeper into ecosystem and use Home Manager for utilities that I use often (and use nix shell/nix run for one offs). Some packages are strictly GUI and while they aren’t handled flawlessly (self-updaters) it’s nice to have them on a single list.
Yet based on your list it’s a definitely a nixventure…
And yet, you are the only(?) one with that knowledge, so the alternative seems to be replying to HN threads with a curated list of things that a user must now open iTerm2 and handle by themselves. Something, unless I'm mistaken, that computers are really good at doing (Gatekeeper and privilege elevation nonsense aside)
Even just linking to the zap portion of your brew cask could go a long way since it would be the most succinct manifest if I correctly understand what it does
I agree this should be documented, but I still appreciate uninstallers.
Also, I'm a little confused about your statement:
> Not sure what the best solution is for people who don't use Homebrew to uninstall it.
You said at the start you've "been meaning to update the Homebrew cask to be more complete on zap" ... does that mean Homebrew uninstall will not do a complete job?
OrbStack is making Docker containers & development environments delightful. Our app replaces Docker Desktop and makes containers faster, lighter, and easier to work with. It's the tool of choice for PlanetScale, Replicate, and other hot companies.
Containers should be a joy to use, not something you have to put up with. Let's build the future of dev envs.
As a founding engineer, you'll mainly work on breaking high-level ideas down into tough systems problems, solving them, and taking ownership of projects. If https://cpu.land and https://docs.orbstack.dev/architecture excite you, you'll be right in place.
(dev here) Yes. I've spent quite a bit of time on scheduling. It's more nuanced than what this article says and there are ways to influence it (but sorry, can't share too many details). OrbStack tends to use E cores more than other virtualization-based apps do on Apple Silicon, especially for heavy workloads.
