Coolify wouldn’t finish deploying on my ARM server. Every restart threw the same line in the logs:

s6-overlay: S6_INITIALIZED not set

The container would start, sit there for a few seconds, then either crash loop or just never become healthy. No stack trace, no obvious config error, just that one line repeating in docker logs every time the container tried to boot. Here’s what caused it and the one line fix.

The setup

I run Coolify as the primary container management layer on a self hosted ARM server. Docker’s data root is on a dedicated mount, and everything gets exposed to the outside world through a systemd managed Cloudflare tunnel. Coolify itself had been running fine for months. This started after a routine update.

I pulled the latest Coolify image, restarted the stack, and that’s when the S6_INITIALIZED errors showed up. My first assumption was a permissions issue with the bind mount, since I’d been burned by that before. It wasn’t that.

The diagnosis

s6-overlay is the init system Coolify’s image uses to manage its internal processes. S6_INITIALIZED is an environment variable the overlay sets internally once its own init sequence has actually completed. If a container image expects that variable to be present and it isn’t, it means the init process never finished starting, which usually means the image itself is broken or was built for a different target than the one it’s running on.

Two things were going on at once, and either one alone might not have caused a full failure, but together they did:

1. The ARM build of the image I’d pulled genuinely didn’t have S6_INITIALIZED set correctly. This turned out to be a real upstream bug in how a specific Coolify build handled ARM images. The overlay initialization sequence that sets this variable wasn’t completing on ARM the way it does on amd64.

2. My .env file had a stale tag. Buried in Coolify’s environment config was:

LATEST_IMAGE=next-aarch64

That next-aarch64 tag isn’t a stable release. It’s a development build tag that gets overwritten frequently and isn’t meant for production use. I had no memory of setting this deliberately. It’s likely I’d pulled it in at some point while troubleshooting an earlier ARM compatibility issue, meant to switch back to a stable tag afterward, and never did. So every time Coolify checked for updates, it was pulling whatever the latest unstable dev build happened to be, not a tested release.

The combination meant I was running an ARM build that had a known, unfixed init bug, and I was doing it on purpose without realizing it, because my own config was telling Coolify to.

The fix

The actual fix was a one-line change:

LATEST_IMAGE=latest

Pointing back at the proper stable release tag instead of the dev channel. After updating the .env file, I pulled the image fresh and restarted:

docker compose pull
docker compose up -d

The container came up clean, S6_INITIALIZED was set as expected, and Coolify’s dashboard was reachable again within a minute.

Are you affected?

Before you assume it’s a permissions or resource problem, check this first. SSH into your server and run:

grep LATEST_IMAGE .env

If that returns anything with next or nightly in the tag name instead of latest or a pinned stable version number, that’s very likely your cause. This is easy to miss because the tag doesn’t look dangerous. It reads like a normal version pin, not a live dev channel.

How to confirm the fix worked

After restarting with the corrected tag, check the logs again:

docker logs <coolify-container-name> --tail 50

A healthy boot won’t mention S6_INITIALIZED at all. If you still see it, or the container is still crash looping, the tag wasn’t the only issue and it’s worth checking disk space and memory next, since Coolify on constrained ARM instances can fail for unrelated resource reasons that produce similar-looking symptoms.

If you’re not on Coolify

This isn’t unique to Coolify. Any image built on s6-overlay can throw the same error if the init sequence doesn’t complete, which happens most often from an architecture mismatch or a broken build being pulled in. If you hit this on a different self-hosted app, the same first move applies: check what image tag you’re actually pulling before you dig into anything more complicated.

Why this is worth writing down

If you’re running Coolify on ARM and you’re seeing S6_INITIALIZED not set in your logs, check your .env for the image tag before you assume it’s a permissions or resource problem.

The broader lesson for myself: any time I set an env var as a temporary workaround, I need to actually go back and revert it once the original problem is solved. This one sat unnoticed for a while because everything mostly worked, until an unrelated update pulled in a dev build with a bug that made the problem visible.

If you hit this and the tag fix doesn’t resolve it, check the Coolify GitHub issues page for anything matching your exact error before assuming it’s local to your setup. If nothing matches, file one yourself with your logs and .env details. Upstream ARM build issues get fixed faster when there’s a clear repro on record.

Coolify is one piece of a larger self-hosted setup I run day to day. If you’re curious what else is in that stack, I wrote up the full list in The Best Self-Hosted Open Source Apps I Actually Use.