Faster incremental CI/CD for Meteor v3 + SolidJS + Vite on ARM64

We found a way to get 5x faster deploy times when the dependencies haven’t changed.

:rocket: The Problem: Building a modern invoicing app with Meteor 3.3, SolidJS, Vite, and ARM64 was powerful but painfully slow to deploy. Every small bug fix required 30+ minutes of waiting.

:bulb: The Solution: Two-tier deployment strategy:
• Full base image via GitHub Actions when dependencies change (~33 min)
• Light overlay for code changes built locally (5-8 min)

:wrench: Key Tech Stack:
• Meteor 3.3 for full-stack framework
• SolidJS for reactive UI
• Vite for lightning-fast builds
• ARM64 for modern cloud efficiency
• CapRover for simple container orchestration

The magic happens with a custom quickdeploy script that creates lightweight Docker overlays, replacing only changed source code files instead of rebuilding everything.

How?

We use github actions to manually trigger a full multi-stage build for ARM64 and push a docker image to ghcr.io. Our action then instructs caprover to pull and run the container. With this layer cached, our quickdeploy script can run on the engineer’s machine to do a meteor build and then package a tarball with the changed code and a new Dockerfile (FROM our deploy image) for direct upload and release.

This is a great enabler for iterating quickly on modern JavaScript applications. When you’re building free tools like our invoicing service at invoicing.productive.me, keeping deployment friction low is crucial for rapid iteration.

Full technical breakdown with code examples in the blog post :point_down:

https://www.productive.me/lightning-fast-ci-meteor3-solidjs-vite-on-arm64/

5 Likes

Do I understand correctly that this is only for development because it relies on a local incremental build?

Do you still run automated tests in your quick deploy process?

Yes, its to speed up the development and releases to a safe environment like staging.

I don’t have much automated tests in this project, since its quite simple by design. But when it grows larger I would adopt this for staging builds and run playwright tests on staging.