| title | Troubleshooting |
|---|---|
| description | Pulling the images fails, the domain does not resolve, ports 80 and 443 are taken, the app refuses to start, the worker keeps waiting, and where the logs are |
| category | self-hosting |
| order | 10 |
docker compose logs app
docker compose logs worker
Run them in the stack folder, /opt/linkedgrow for an install that took the default. Every compose command on this page expects the root account that installed the stack, or sudo in front of it.
Add -f to follow, or --tail 200 for the last lines only. docker compose ps shows which of the 3 services is running and whether the app is healthy.
The app checks what it needs before anything else and stops with one line on the reason. A normal install has nothing to get wrong here, because it generates its own secrets and reads its address off each request. The 2 lines you can still see come from values you set yourself. ENCRYPTION_KEY is set but is not 64 hex characters means the value in the environment is wrong, and the app refuses rather than generating a replacement that would leave the database unreadable. /data/config is not writable or the same about /data/uploads means the volume came up owned by root, and the line itself carries the one command that fixes it. Correct the value and run docker compose up -d again.
Two factor on a LinkedGrow account is checked against a secret held on that account's own row, so no reset link and no support address gets past it. The instance ships a command that clears those fields for one address, and the account then signs in with its password alone. Run it from the stack folder, the same place every other compose command on this page runs:
docker compose exec app npm run db:clear-2fa -- you@example.com
It names the address it cleared, and it stops with a message when no account on this instance uses that address. The account keeps everything else, its agents and its posts included. Sessions opened before the command runs are signed out, so a second browser that was still signed in has to sign in again. Switch two factor back on from Settings once you are in, because the stored secret is gone and the old QR code no longer works.
worker: waiting for the app repeating in the worker log is the worker polling the app's health check, which only passes once the database is reachable and the migrations have run. Look at the app log for the reason: a configuration problem as above, or the database container still opening on a slow disk, which the app retries for a minute on its own. The worker starts by itself as soon as the app answers.
denied or manifest unknown on docker compose pull means the registry will not hand over the image. The repository is private until launch, so sign in first with a GitHub token that carries the read:packages scope:
docker login ghcr.io -u YOUR_GITHUB_USER
Paste the token as the password. The other way through is to build the images on the server instead, with ./install.sh --source or the build override described on the install page, which needs no registry at all. A manifest unknown on an arm64 host usually means something else, because latest is built for amd64 only, so pick a release tag or build from source.
The installer warns when the domain resolves somewhere else, or nowhere, and starts the stack anyway. Caddy cannot get a certificate in that state, and the browser shows a connection error rather than a page. Add an A record pointing at this server, wait for it to propagate, check it with dig +short linkedgrow.example.com, then run docker compose restart caddy and watch docker compose logs caddy for the line that says the certificate was obtained. Let's Encrypt limits how often it accepts a failing request for the same name, so fix the record before restarting Caddy in a loop.
bind: address already in use on the caddy container means another web server holds the port, usually an nginx or an Apache installed with the machine. Either stop it (systemctl stop nginx), or keep it and let it do the https work, which means emptying COMPOSE_PROFILES, running docker compose up -d, and pointing your existing server at port 3000 with one of the blocks on the reverse proxy page. ss -tlnp | grep -E ':(80|443)' names the process holding the port.
Their API only answers from addresses on the allowlist in their dashboard, at most 3 of them, and the message says the IP is not allowed. Add the server's public address, the one shown on the wizard step. The app calls their API over IPv4 on purpose, so the address to add is the IPv4 one even when the server also has IPv6. After a move to another server, add the new address before the worker needs to buy or renew anything.
No AI key is configured for the agents. Add one in Settings, Instance. means the wizard's AI step was skipped or the key was removed. Add a key on that page and test it; the agent stays paused until you start it again from the agents page.
Google Chrome ships for amd64 only on Linux, so on an arm64 host the worker image installs Chromium and the entrypoint sets CHROME_PATH=/usr/bin/chromium. It works, and LinkedIn can tell Chromium apart from Chrome more easily, so treat arm64 as a way to try the product and run production on amd64. On an Apple Silicon Mac used for development, a docker-compose.override.yml next to the compose file, containing services: worker: platform: linux/amd64 on 3 lines, runs the amd64 Chrome image under emulation instead.