User experience story
CyberCharles installs Sindri locally: the real story
4 min read
This is the honest install diary from the first attempt to the moment the registry accepted a real artifact, including the port conflict, the Docker diagnosis, and the workaround that finally worked.
The first step was simple and then confusing
We cloned the upstream Sindri repo, read the project docs, and followed the recommended local workflow. The README was clear enough to start, but the first real problem arrived immediately when the app tried to connect to Postgres and hit a connection refused error on 127.0.0.1:55432.
The environment was the real bottleneck
The database containers looked healthy, and the app was making the expected connection request. The mismatch was that the service was running in a rootless Docker environment, and the host was not correctly reaching the published port. That meant the issue was environmental, not a code bug in the project itself.
The workaround that actually worked
We installed PostgreSQL directly on the host, created the expected sindri role and database, and then ran the app with the host database override. Once the app pointed at the reachable local database, it migrated cleanly and started serving on 127.0.0.1:8080. The fix was simple in hindsight but it required a real debug pass and a bit of patience.
The first image finally landed
After the service was healthy, the real proof came from a literal push: we logged in with the dev token, tagged an Alpine image, and pushed it to the local registry. The registry accepted the image and the first artifact was in. That was the moment the local install stopped being theoretical and became real.
What we learned
The install story is not a polished launch story. It is a real-world story about environment drift, Docker networking, and the value of testing the exact assumptions that the project makes. The app itself was sound. The runtime conditions were the part that required work. more tomorow....