Server troubleshooting

The most common issues when self-hosting, and how to fix each one. If you’re stuck after this, grab your logs (docker compose logs or journalctl -u socialmate) and contact support.

I can’t reach http://<ip>:3456/admin

Work through these in order:

1. Is it running? On the server, curl -fsS http://localhost:3456/health. If that fails, the server isn’t up — check docker compose ps / systemctl status socialmate and the section below.
2. Firewall. If localhost works on the server but you can’t reach it from your computer, port 3456 is blocked. Open it: sudo ufw allow 3456 (and check your VPS provider’s cloud firewall / security group too).
3. Right address. Use the server’s public IP, not localhost, from your own machine — and include :3456 and the /admin path.

The container is “unhealthy” or won’t start

Read the logs first — they almost always say why:

docker compose logs --tail 50 socialmate

Most common cause: the admin password is shorter than 8 characters (the server refuses to start with a weaker one). Fix it in .env and recreate:

nano .env          # set a password of 8+ characters
docker compose up -d --force-recreate

On systemd, the equivalent logs are journalctl -u socialmate --no-pager -n 50, and the password lives in /etc/socialmate/socialmate.env.

If the log says “Another SocialMate server is already running on this data directory”, that’s the single-instance guard: one server per data dir (two would corrupt the database). Stop the other copy first. A crashed instance is detected and taken over automatically within ~15 seconds, so this usually clears itself on the next start.

Reset a lost admin password

If you can still sign in, don’t do this — just change your password in Settings → Server (see Keep your server running). The steps below are only for when you’ve lost it and can’t sign in at all.

Your password is set once, on the first boot, and after that SOCIALMATE_ADMIN_PASSWORD is ignored — the stored password wins. So to recover, clear the stored password so the server re-reads your env value on the next start.

Docker:

docker compose stop
docker compose run --rm --entrypoint node socialmate 
  -e "require('better-sqlite3')(process.env.HOME+'/.wa-agent-server/wa-agent.db').exec('DELETE FROM admin_auth; DELETE FROM admin_sessions;')"
nano .env          # set SOCIALMATE_ADMIN_PASSWORD to your new password (8+ chars)
docker compose up -d

systemd:

sudo systemctl stop socialmate
sudo -u socialmate HOME=/var/lib/socialmate /usr/bin/node 
  -e "require('/opt/socialmate/node_modules/better-sqlite3')(process.env.HOME+'/.wa-agent-server/wa-agent.db').exec('DELETE FROM admin_auth; DELETE FROM admin_sessions;')"
sudo nano /etc/socialmate/socialmate.env   # set SOCIALMATE_ADMIN_PASSWORD
sudo systemctl start socialmate

If you leave the password blank instead, the server generates a new one and prints it to the logs on the next start, exactly like a first install.

Login says I’m locked out

After several wrong passwords the login throttles with a growing delay (up to 15 minutes) to stop brute-forcing. It’s not permanent — wait for the delay to pass and log in with the correct password. If you don’t know the password, reset it above.

Port 3456 is already in use

Something else is on that port. On Docker, change the host side of the mapping in docker-compose.yml — for example "8080:3456" — then docker compose up -d and use :8080 in your browser. On systemd, set SOCIALMATE_API_PORT=8080 in /etc/socialmate/socialmate.env and sudo systemctl restart socialmate.

It dropped to Free / lost my Pro on the server

Almost always this means the data dir wasn’t persisted, so the machine id your license is bound to changed. Keep one stable data volume (Docker: the sm-data volume; systemd: /var/lib/socialmate) and never recreate it between restarts. See licensing on a server. If the volume is intact and it still shows Free, check your device isn’t deactivated in your account portal.

Still stuck — open a ticket · Back to all articles