x86 and non-Pi ARM64 support — installer script for existing Linux systems

[papadopouloskyriakos]

We've had several requests for running CubeOS on hardware other than Raspberry Pi — OrangePi boards, Proxmox VMs, old laptops, mini PCs, and regular x86 servers.

Right now CubeOS ships as a pre-built SD card image for Raspberry Pi 4/5. But underneath, it's Docker Swarm stacks + a Go API + a Go HAL daemon — none of that is Pi-specific. The Pi-only constraint comes from the image builder, boot scripts, and WiFi AP configuration, not from the core platform.

The plan: A curl | bash installer script (similar to how CasaOS installs) that sets up CubeOS on any existing Ubuntu/Debian system — ARM64 or x86. It would:

• Install Docker if not present
• Initialize Docker Swarm
• Deploy the CubeOS stack (API, HAL, Dashboard, Pi-hole, NPM, registry)
• Set up the data directory and configuration

Pi-specific features like the WiFi access point, GPIO, and boot scripts would be optional or skipped on non-Pi hardware. The dashboard, app store, self-healing containers, and HAL hardware discovery would work everywhere.

This also opens the door for CasaOS migration — since CasaOS apps are standard Docker containers with compose files, an installer that runs alongside existing containers makes the transition smoother.

What hardware would you run CubeOS on? Drop a comment with your setup — it helps prioritize what to test first.

[chchia]

hi, i would suggest to also consider allow user to select if they really need docker swarm, i think not everyone get benefit from swarm.

i am the one asked in Reddit, so here my hardware:

1. OrangePi 5+ 16GB
2. OrangePi Zero 3 2GB
3. Raspberry Pi 5 8GB
4. Raspberry Pi 4B 4GB
5. other proxmox server.

i would be happy to be tester if you have the package ready.

[papadopouloskyriakos]

Welcome, and thanks for listing your hardware — that's exactly the kind of input that helps prioritize. OrangePi 5+ with the RK3588 NPU is high on the list.

Great question on Swarm. The short answer: on a single node, Swarm has near-zero overhead over plain Compose, but gives you self-healing, rolling updates, secrets management, and desired-state reconciliation for free. The longer answer:

Why Swarm is non-optional in CubeOS:

CubeOS is designed to run unattended — on a shelf, in a vehicle, at a remote field station. Nobody is SSH'd in watching it. The core question isn't "do I want Swarm" but "do I want my containers to recover automatically at 3 AM when nobody's looking."

With plain Compose, restart: unless-stopped is your only recovery mechanism. It handles simple crashes. But Swarm gives you:

• Desired-state reconciliation — Swarm continuously compares actual state vs declared state and corrects drift. If a container dies, if a config changes, if something gets into a bad state — Swarm fixes it without human intervention.
• Rolling updates — zero-downtime deployments. Update the API container without dropping active requests.
• Secrets management — encrypted at rest, injected at runtime. No plaintext passwords in compose files.
• Multi-node ready — when you want to add a second Pi (or OrangePi) to the cluster, it's docker swarm join. No migration, no re-architecture.

The overhead misconception:

Single-node Swarm is literally docker swarm init — one command. It's the same Docker daemon with an extra reconciliation loop. There's no etcd cluster, no control plane pods, no API server eating 500MB of RAM. It's not Kubernetes. On a Raspberry Pi 4 with 4GB RAM, the Swarm overhead is unmeasurable.

The honest downsides:

• Docker Inc has deprioritized Swarm (no major new features since ~2019). But it ships with every Docker Engine install and is stable.
• Community perception is "deprecated" — it's not. It's just not getting new features. For what CubeOS needs, it's feature-complete.
• ARM64 image manifests sometimes need --resolve-image never as a workaround.
• Debugging uses docker service logs instead of docker logs (the CubeOS dashboard abstracts this away).
• You can't docker compose up directly — it's docker stack deploy. But the CubeOS API handles all of this; users never touch these commands.

What about CasaOS-style Compose for simplicity?

CasaOS used plain Compose and had no self-healing beyond restart: unless-stopped. If a container got into a crash loop, you had to SSH in and fix it manually. If your SD card corrupted mid-write during a compose update, you had a half-deployed stack with no rollback. CubeOS avoids both of these — Swarm handles the first, and our FlowEngine (saga-pattern) handles the second by rolling back incomplete multi-step operations automatically.

The user never interacts with Swarm directly. The dashboard and API abstract everything. From the user's perspective, they click "install" and the app appears. Whether Swarm or Compose is underneath is invisible. But when something goes wrong at 3 AM, Swarm is the reason it fixes itself.

That said — for the curl | bash installer on existing systems, I'm considering detecting if the user already has Compose-based containers running and offering to manage them alongside Swarm stacks during the migration period. So existing setups aren't disrupted.

Re: testing — noted! I'll tag you when the installer script is ready for first testers. Your hardware spread (OrangePi 5+, Zero 3, Pi 5, Pi 4B, Proxmox) is basically the perfect test matrix.

[Hippyjake]

I would love to run this on an old Intel laptop that was running casaOS

[papadopouloskyriakos]

That's the exact scenario the installer is targeting — an old laptop with an existing Linux install is actually the ideal x86 test platform. What distro are you running on it, and is CasaOS still installed or have you already removed it?

[Hippyjake]

Debian. I have already removed Casaos. I've been testing other self hosting solutions and have not been happy with the use of self signed certificates (it breaks the jellyfin Roku app).
It will be a clean installation of Debian

[papadopouloskyriakos]

Clean Debian is perfect — that's the primary target for the installer.

The self-signed cert pain is one of the reasons CubeOS includes Nginx Proxy Manager and Pi-hole in the stack. CubeOS has three access profiles that control how apps are reached:

• Standard (default) — apps via IP:port. CubeOS doesn't touch your network's DNS or DHCP. This is what an x86 laptop on a home LAN would use.
• Advanced — same as Standard, but CubeOS auto-configures your existing NPM and Pi-hole via their APIs. Power user setup.
• All-in-One — CubeOS manages everything: DNS, DHCP, reverse proxy. Apps get clean URLs like jellyfin.cubeos.cube. Currently this requires AP mode (Pi with WiFi), but we're planning to extend it so CubeOS can also serve as the DHCP/DNS authority on a wired LAN — which is exactly your laptop scenario.

In Standard or Advanced mode, NPM can still provision real Let's Encrypt certs via DNS challenge when you're online — no self-signed certs, no Roku breakage. You'd just access apps through https://jellyfin.yourdomain.com instead of the .cubeos.cube internal domain.

The current alpha is still plain HTTP while the core platform stabilizes, but the infrastructure for proper certs is already there — it's configuration, not new code.

I'll tag you alongside @chchia when the installer is ready for testing. Debian x86 clean install is a day-one test case.

[chchia]

Hi @papadopouloskyriakos I had installed your latest script on a PVE X86 Debian Trixie, so far it is working, i was impress that you had already complete so much.

by the way if i may suggest, perhaps it will be better to set the font size bigger.

you even have the gpio, i2c integrated, that really amaze!

i will try to do more testing, and congratulation for this fantastic and promising NAS platform that you are working on.

[papadopouloskyriakos]

Thanks for testing! PVE x86 Debian Trixie is a great data point, glad it came up clean.

Good call on the font size, I'll look into that. The dashboard is designed mobile-first so some elements might feel small on a larger screen. What resolution are you running it at?

The GPIO and I2C are part of the HAL, they're more useful on Pi and OrangePi hardware but the detection runs everywhere. On x86 it'll just report nothing found, which is the correct behavior.

Appreciate the continued testing, keep the feedback coming.

[chchia]

i am on a 1080p screen with 100% DPI.

how do i update if there is a new version? can i just simply use watchtower to pull latest images? or will there be something else that i need to update in the underlaying system?

some comments:

1. portainer in app store does not connect to local docker, i suspect it doesnot have -v /var/run/docker.sock:/var/run/docker.sock in default config. it seem the mount point is incorrect for docker-sock, docker inspect show:

            "Mounts": [
                {
                    "Type": "bind",
                    "Source": "/cubeos/apps/big-bear-portainer/appdata/data",
                    "Target": "/data"
                },
                {
                    "Type": "bind",
                    "Source": "/cubeos/apps/big-bear-portainer/appdata/docker-sock",
                    "Target": "/var/run/docker.sock"
                }
            ],

2. i am sure you had already consider this, but letting user to amend the docker command before composing might be a good way to prevent such issues, including to let user to edit their own mount point.

3. allowing user to edit the link to open from apps list, example my Portainer with link at http://192.168.1.215:6101 , however Portainer reuqired to open by https:// instead of http:// and i cannot find a way to edit the link yet.

i will spend some more time to test. and thank you for the work.

[papadopouloskyriakos]

Great feedback, addressing each one:

Updates: re-running the install script will pull the latest images and redeploy. A proper one-click updater in the dashboard is planned but not there yet. Watchtower won't work because CubeOS uses Swarm stacks, not standalone containers. But honestly even with regular Compose, Watchtower auto-updating is risky. Breaking changes, bad migrations, config format changes — it just pulls latest blindly. Controlled updates are always better.

1. Portainer docker.sock: yep that's a bug in the compose transformer. It's rewriting the volume source to the app data directory instead of preserving the host socket path. Will fix.

2. Edit compose before deploy: noted, this is on the roadmap as an advanced install option.

3. App URL edit: this is already in the next release. Should be live soon.

Keep them coming, this is exactly the kind of feedback that shapes the beta.