Forem: Pat Teruel

The Hidden Cost of Self-Hosting Mobile CI/CD (Gitea + React Native)

Pat Teruel — Mon, 23 Mar 2026 02:08:00 +0000

I thought Android CI/CD would be the easy part.

After all, it works perfectly on GitHub Actions.

So I tried to self-host it using Gitea.

That’s where things started breaking.

Context

In my previous posts, I’ve been experimenting heavily with Lima VMs to create isolated development environments.

Separate environments per project
No dependency conflicts
Full control over provisioning

It worked surprisingly well.

I even managed to:

Run self-hosted CI/CD using Gitea Actions
Spin up a macOS runner for iOS builds
Automate xcodebuild and generate IPAs

At that point, I thought:

“If I can make iOS work… Android should be easy.”

The Plan

I’m currently building a personal app using:

React Native
Expo

I already have another app with the same stack running on GitHub Actions — no issues at all. Smooth builds, predictable pipelines.

So the idea was simple:

Reuse the same workflow… but run it on my own infrastructure.

Photo by Ferenc Almasi on Unsplash

Attempt #1 — Linux ARM + Docker (Lima VM)

Since I’m on an Apple Silicon Mac, I started with:

Ubuntu (ARM) VM via Lima
Docker-based Gitea runner

This setup worked well for other projects.

But for React Native?

❌ It failed.

The error wasn’t immediately clear, but one thing kept popping up:

Hermes

Attempt #2 — Manual Environment Setup

I thought maybe Docker was the issue.

So I went manual:

Installed JDK
Installed Android SDK
Installed Node.js
Configured environment variables

After hours of setup…

❌ Same failure.

Photo by Vitaly Gariev on Unsplash

💡 First Realization

Setup ≠ Compatibility

Just because you can install everything correctly…

doesn’t mean everything will actually work together.

The Breakthrough (and the Wall)

After digging deeper, I found the real issue:

Hermes does not support Linux ARM.

And suddenly everything made sense.

Other people were hitting the same wall:

💡 Second Realization

Mobile tooling is tightly coupled to platform constraints.

This isn’t just “Node + build tools”.

You’re dealing with:

Native engines (Hermes)
Platform-specific binaries
Architecture limitations (ARM vs x86)

Attempt #3 — “Let’s Use My Homelab”

Okay. If ARM is the problem…

Let’s switch to x86.

I tried running the build on my homelab:

Old Intel MacBook Pro
8GB RAM
Running services like Jellyfin

What could go wrong?

💥 Everything.

The server crashed due to memory exhaustion.

Photo by Denny Bú on Unsplash

💡 Third Realization

Infrastructure matters more than correctness.

Even if your setup is “technically correct”…

If your hardware can’t handle it, it doesn’t matter.

Attempt #4 — x86 VM via QEMU (Back to Lima)

Back to my Mac.

This time:

Ubuntu x86 VM
Running via QEMU emulation

And finally…

✅ It runs.

But there’s a catch.

⏳ It’s slow.

Like… 40+ minutes per build slow.

Photo by John Moeses Bauan on Unsplash

💡 Fourth Realization

Emulation works — but at a cost.

You can force compatibility…

But you pay for it in:

Performance
Time
Developer experience

The Bigger Picture

At this point, I had to stop and ask:

“Why does this work so easily on GitHub Actions?”

🧠 Insight #1 — Cloud CI Hides the Hard Parts

When you use platforms like GitHub Actions:

You don’t think about CPU architecture
You don’t manage SDK installations
You don’t deal with compatibility issues

Because they already solved it.

You’re not just using CI/CD.

You’re using pre-solved infrastructure.

🧠 Insight #2 — Mobile CI/CD Is Not Platform-Agnostic

Backend CI/CD is relatively straightforward.

Mobile?

Not even close.

You’re tied to:

OS constraints (macOS for iOS)
CPU architecture (ARM vs x86)
Vendor tooling (Android SDK, Hermes, etc.)

🧠 Insight #3 — Self-Hosting Means Owning Everything

When you self-host CI/CD, you’re not just replacing GitHub Actions.

You’re taking ownership of:

Environment provisioning
Toolchain compatibility
Hardware limitations
Performance tradeoffs

Photo by Digital Reach on Unsplash

So… Was It Worth It?

❌ Not worth it if you want:

Fast builds
Simple pipelines
Zero maintenance

✅ Worth it if you want:

Full control over your pipeline
No dependency on third-party CI providers
Deep understanding of how everything works
A system you can run entirely on your own machines

The Tradeoff No One Talks About

If I get this fully working, production-ready, and stable…

I technically have:

A fully self-hosted CI/CD pipeline for mobile apps

No GitHub Actions.

No CircleCI.

No per-minute billing.

Just:

My machines
My setup
My electricity bill
And… my sanity 😅

💡 Final Realization

You’re not paying with money anymore.

You’re paying with complexity.

Cloud CI/CD:

Pay with money
Save time and mental load

Self-hosted CI/CD:

Save money (long-term)
Pay with time, effort, and maintenance

My Take

Will I still use GitHub Actions?

Probably — especially when I just want things to work.

But I’m no longer dependent on it.

Because now I know:

I can run everything on my own infrastructure.

And that changes how I think about building systems.

What’s Next

I still have one idea left:

Using a macOS VM (ARM via Apple Virtualization)
Running builds natively without emulation

In theory, this should:

Avoid Hermes issues
Improve performance significantly

If that works…

This setup might actually be viable — even for production.

Final Thought

Self-hosting CI/CD for mobile isn’t just replacing a tool.

It’s taking ownership of the entire environment.

And once you take that ownership…

You also get the freedom to decide:

Do I want to pay with money — or with complexity?

Photo by engin akyurt on Unsplash

Lima VM — Life Changing? Or a Passing Fad?

Pat Teruel — Sat, 21 Mar 2026 02:36:19 +0000

Photo by Daniil Komov on Unsplash

I accidentally built a self-hosted iOS CI pipeline

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.

It Started With a Simple Problem

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.

One Project, Two Machines

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

The setup wasn’t smooth.

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.

Then I Got Curious (Again)

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.

Running My Own CI Runners

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.

The Real Goal: iOS Builds

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?

macOS Inside macOS (Yes, Really)

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.

This Part Was Painful

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…

It Worked

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.

Photo by Baltasar Henderson on Unsplash

What I Have Now

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.

What I Learned: Provisioning Lima & Creating Templates

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.

Why I’m Doing This

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.

Is Lima VM “Life Changing”?

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.

What’s Next

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

Lima VM & faasd: A Beginner’s Experiment With Isolated Development Environments

Pat Teruel — Mon, 16 Mar 2026 03:36:15 +0000

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

Photo by Jexo on Unsplash

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.

References

I've Spent 10 Years in Mobile Development. What DON'T I Know?

Pat Teruel — Sun, 08 Mar 2026 17:42:53 +0000

For the past decade, I’ve worked primarily as a mobile developer, focusing on iOS and mobile platforms. That has been my professional identity for most of my career, and it’s something I’m genuinely passionate about.

But recently, I started asking myself a difficult question:

After 10 years in mobile development, what don’t I know?

Photo by Douglas Lopes on Unsplash

A Mobile Developer With Curiosity

Even though I’ve always identified professionally as a mobile developer, my curiosity has never been limited to mobile.

Over the years, I’ve explored different parts of the tech stack through personal projects and experiments. I've built small backend services using Java and Kotlin with Spring Boot, experimented with NodeJS, worked with Flutter and Firebase on a side project with a friend, and learned how to deploy services using Docker and AWS.

Outside of work, I’ve also built my own small homelab to host services for personal use. These projects weren’t part of my main job, but they helped me understand how different parts of a system work together.

Despite all of that exploration, my day-to-day professional identity remained the same:

Mobile Developer.

And I was comfortable with that.

When Your Role Changes

At one point, I recommended a project internally and eventually found myself overseeing it from a project management perspective.

I learned a lot about planning, coordination, and the processes required to bring a product to production. But I also realized something important about myself.

My brain isn’t wired for project management.

What excites me most is still the engineering work itself: designing systems, writing code, building infrastructure, and figuring out how different parts of a product fit together.

So even while overseeing the project, I naturally gravitated back toward engineering tasks — setting up CI/CD pipelines with GitHub Actions, managing parts of the AWS infrastructure, and helping with the technical architecture.

That experience reinforced something I already suspected:

I enjoy building systems.

The Realization

As I interacted with engineers working in different stacks — backend engineers, infrastructure specialists, and full-stack developers — something slowly became clear to me.

Even with ten years of experience, I was still an amateur in the broader technology landscape.

And that’s not necessarily a bad thing.

Technology is far too large for any one person to fully master. Every engineer specializes somewhere. But realizing the size of that landscape made me rethink the direction of my own growth.

Rethinking My Path

Instead of staying within a single specialization, I want to expand my perspective as an engineer.

Not by abandoning mobile development — far from it. Mobile development will always be a major part of what I do.

But I want to better understand the systems behind the applications we build:

Backend architecture
Infrastructure and deployment
Data modeling
CI/CD and operational systems
End-to-end product development

In other words, I want to grow into what I think of as a Product Engineer — someone who can understand and contribute to a product from idea to deployment.

In the Era of AI

We’re entering a period where AI tools are becoming a normal part of software development.

Some developers respond to this with fear — worrying that automation might replace parts of our jobs.

Personally, I see it differently.

If anything, this era makes it more important to broaden our understanding of systems. AI can help generate code, but building reliable products still requires engineers who understand architecture, trade-offs, and how different components interact.

For me, that means continuing to learn, experiment, and expand beyond my original specialization.

The Next Step

So I’ve decided to take a step back and map out the gaps in my own knowledge.

Not as a criticism of where I am today, but as a roadmap for where I want to go next.

My goal is to gradually build deeper experience across the full lifecycle of a product — from writing code to designing systems and running them in production.

The first step is simple:

Build something end-to-end.

A real application, with real infrastructure behind it.

And document the journey along the way.

Mobile development isn’t going anywhere in my career. It will always be one of the areas I care about most.

But moving forward, I want to challenge myself to build not just apps — but the entire systems behind them.