Lima VM — これが生命を変えるのか、それとも一時的な流行なのか？

数日前、Lima VMを発見しました。 最初は単なる好奇心でした。私の開発環境を分離し、常にローカルマシンと戦うことに疲れることなく、よりクリーンな方法を求めていました。 これがこうなるとは予想もしていなかったのですが： 今私は、Mac の内部で macOS VM を実行して iOS アプリを構築する自己ホスト型 CI パイプラインを持っています。 多くの開発者と同様に、私は環境を調整しています： 開発環境 vs ステージング環境 異なる .env セットアップ 互いを干渉する Docker コンテナ すべては機能しましたが、決してクリーンなものを感じませんでした。 したがって、別の方法を試みました。 単一のマシンがすべてを担当するのではなく、1 つのプロジェクトを 2 つの Lima VM に分割しました： Dev VM → ホットリロード、高速な反復 Staging VM → 変更をプル、生产用イメージを構築、テスト 各 VM は独自のホスト名を持っていました： lima-project-dev.local lima-project.local コンフリクトはありません。奇妙なコンテナの重複はありません。「待って、今はどの環境にいるの？」という疑問もありません。 Photo by Heliberto Arias on Unsplash 私は以下を処理する必要があります： Lima YAML 設定を整理する プロジェクトを正しくマウントする VM 内の git を再設定する 数回の試行錯誤、多くのトライ＆エラーを要しました。 しかし、それが機能したとき： それはまるで異なりました。 私は既に月単位でホメラベルに Gitea を実行してきました。 私はそれが Actions（GitHub Actions に類似）をサポートしていることを知っており、完全に妥協したことはありませんでしたが、理由は以下の通りでした： 「ランナーはどこで実行すればよいのか？」 その質問は以前は私の動機を基本殺してしまいました。 until Lima. それより深く考える代わりに、私は別の VM を起動しました。 Gitea Act Runner をインストールし、自分のインスタンスに接続しました。 そして…それは機能しました。 今私は完全自己ホスト型のプライベートリポジトリの CI 任務を実行しています。 Photo by Jake Walker on Unsplash それだけで既に勝利を感じました。 しかし、私は満足ではありませんでした。 iOS 開発者として、常に一つの限界があります： iOS アプリをビルルドするために macOS が必要です。 クラウド CI はこれを解決します。GitHub Actions もこれを解決します。 しかし私は以下を見たいのです： 私は自分でこれができるのか？ 最近、Lima は実験的な macOS VM サポートを導入しました。 したがって、私はそれを試しました。 私の Mac の内部で macOS VM を設定しました。 次に、それを CI ランナーに変える試みを行いました。 セットアップは容易ではありませんでした。 手動で以下のものをインストールして設定する必要があります： Xcode Node.js Cocoapods React Native Expo 依存関係 ことは壊れました。 非常に多く。 ある時点で、私は「ランダムな修正を試み続ける」ことを止め、すべてを文書化するように始めました。 最終的に、私は自分の再実行可能なセットアップガイドを作成しました。 その後、VM をクリアし、最初から再構築しました。 私の手順に従いました。 そして最後に… 私は Gitea Action をトリガーしました。 ランナーはそれを受け取りました。 macOS VM はそれを実行しました。 そして私は以下を得ました： xcodebuild を使用して生成された iOS ビルドアーチファクト。 私の自分の自己ホスト型パイプラインから。 GitHub Actions ではありません。外部の CI ではありません。 単に： Gitea Lima VM 私の自分のマシン その瞬間は正直に信じられないほど感動的でした。 Baltasar Henderson on Unsplash 現在、私のセットアップは以下のようになっています： 開発用/ステージング用の複数の Lima VM 一般的な CI 用 Ubuntu ランナー iOS ビルド用の macOS VM ランナー すべてを編曲する Gitea Actions 今私は以下をすることは可能です： iOS アプリを自動的に構築する 署名されていない IPA を生成する それらを自分のディストリビューションシステムにデプロイする（進行中） Small Limitations (For Now) それは完璧ではありません。 例えば： Gitea Actions は現在アップロード・アーチファクトに v3 までをサポートしています 最新のバージョン（v6）はまだ完全にサポートされていません しかし正直に言えば？ それは小さなトレードオフです。 必要に応じて、私はアーチファクトを別のサーバーにプッシュすることができます。 この経験から得た最も価値あるものとは、すべてが機能することではなく、Lima VM を正しくプロビジョニングし、再利用可能なテンプレートを作成する方法を学ぶことでした。 ゼロから macOS VM をセットアップするのは容易ではありません。それは多くのトライ＆エラー、デバッグ、再デプロイを涉及しました。しかし、そのプロセスは私が Lima の構成がより深いレベルでどのように機能するかを理解するのを強制しました、特にその YAML ベースのプロビジョニングシステム。 そしてそれはすべてを変えました。 各 VM を単発のセットアップとして扱うのではなく、テンプレートという概念で考えられるようになりました。 この点から、私は私の own ワークフロー用のカスタム Lima テンプレートを作成できます： 新しいプロジェクト開発用新鮮な VM を起動する 事前構成されたテンプレートを作成して...

Photo by Daniil Komov on Unsplash A few days ago, I discovered Lima VM. At first, it was just curiosity. I wanted a cleaner way to isolate my development environments without constantly fighting my local machine. I didn’t expect it to turn into this: I now have a self-hosted CI pipeline that builds iOS apps using macOS VMs running inside my Mac. Like most developers, I was juggling environments: development vs staging different .env setups Docker containers stepping on each other Everything worked… but it never felt clean. So I tried something different. Instead of one machine handling everything, I split a single project into two Lima VMs: Dev VM → hot reload, fast iteration Staging VM → pull changes, build production images, test Each VM had its own hostname: lima-project-dev.local lima-project.local No conflicts. No weird container overlaps. No “wait, which environment am I in?” Photo by Heliberto Arias on Unsplash I had to: figure out Lima YAML configs mount projects correctly reconfigure git inside the VM It took a few retries. A lot of trial and error. But once it worked? It felt different. I’ve been running Gitea in my homelab for months. I knew it supported Actions, similar to GitHub Actions—but I never fully committed to it because: “Where do I even run the runners?” That question basically killed my motivation before. Until Lima. Instead of overthinking it, I spun up another VM. Installed the Gitea Act Runner. Connected it to my instance. And… it worked. I was now running CI jobs for my private repositories—fully self-hosted. Photo by Jake Walker on Unsplash That alone already felt like a win. But I wasn’t satisfied. As an iOS developer, there’s always one limitation: You need macOS to build iOS apps. Cloud CI solves this. GitHub Actions solves this. But I wanted to see: Can I do this myself? Lima recently introduced experimental macOS VM support. So I tried it. I set up a macOS VM… inside my Mac. Then I tried to turn it into a CI runner. Setting it up was not easy. I had to manually install and configure: Xcode Node.js Cocoapods React Native Expo dependencies Things broke. A lot. At some point, I stopped “trying random fixes” and started documenting everything. Eventually, I built my own repeatable setup guide. Then I wiped the VM. Recreated it from scratch. Followed my own steps. And finally… I triggered a Gitea Action. The runner picked it up. The macOS VM executed it. And I got: An iOS build artifact generated using xcodebuild. From my own self-hosted pipeline. No GitHub Actions. No external CI. Just: Gitea Lima VM My own machines That moment honestly felt incredible. Baltasar Henderson on Unsplash Right now, my setup looks something like this: Multiple Lima VMs for dev/staging Ubuntu runners for general CI macOS VM runner for iOS builds Gitea Actions orchestrating everything I can now: Build iOS apps automatically Generate unsigned IPAs Deploy them to my own distribution system (work in progress) Small Limitations (For Now) It’s not perfect. For example: Gitea Actions currently supports upload-artifact up to v3 Newer versions (v6) aren’t fully supported yet But honestly? That’s a small tradeoff. If needed, I can just push artifacts to another server. One of the most valuable things I gained from this experience wasn’t just getting everything to work—it was learning how to provision Lima VMs properly and create reusable templates. Setting up a macOS VM from scratch was not easy. It involved a lot of trial and error, debugging, and repeated deployments. But that process forced me to understand how Lima’s configuration works at a deeper level, especially its YAML-based provisioning system. And that changed everything. Instead of treating each VM as a one-off setup, I can now think in terms of templates. From here on out, I can create custom Lima templates for my own workflows, such as: Spinning up a fresh VM for new project development Creating pre-configured Ubuntu runners for Gitea Actions Preparing environments with Docker and commonly used services already set up Bootstrapping CI/CD tools without installing anything directly on my host machine This turns Lima into more than just a VM tool—it becomes a foundation for repeatable, disposable infrastructure. The initial setup may be painful, but once you’ve built your own provisioning templates, every new environment becomes significantly faster and more consistent. And for me, that’s probably one of the biggest wins from this entire experiment. Partly? Because it’s fun. But also: I want to understand how CI/CD actually works under the hood I want control over my infrastructure I want to build systems—not just use them This isn’t about replacing GitHub Actions. It’s about learning by building the system yourself. Too early to say. But right now? It already changed how I think about: development environments isolation automation self-hosted infrastructure Even if I stop using it someday… This experiment was already worth it. Explore ephemeral runners Improve VM provisioning (less manual setup) Integrate into a real product workflow Write a step-by-step guide for macOS runners References https://lima-vm.io/ https://lima-vm.io/docs/usage/guests/macos/ https://about.gitea.com/ https://docs.gitea.com/usage/actions/act-runner