Updating Sloth Manager

This guide covers the full workflow from making changes in development to deploying them to production.

Development workflow

1. Make your changes locally

Run the app in development mode while making changes:

# Terminal 1 — backend
cd backend
npm run dev

# Terminal 2 — frontend
cd frontend
npm start

Test your changes at http://localhost:3000.

2. Commit to Gitea

When you are happy with the changes:

cd dns-manager

# Review what changed
git status
git diff

# Stage and commit
git add .
git commit -m "Short description of what changed"

# Push to Gitea
git push

Deploying to production

On your production server

# 1. Pull the latest changes from Gitea
cd /path/to/dns-manager
git pull

# 2. Rebuild and restart the containers
docker compose up -d --build

That's it. Docker will rebuild only the layers that changed, so subsequent builds are faster than the first.

What happens during an update

The Docker images are rebuilt with the new code
The containers are replaced with the new images
The ./sloth-data volume is untouched — all your data (users, DNS cache, secrets, IP addresses, audit log, settings) is preserved
Downtime is typically a few seconds while the new containers start

Verifying the update

After deploying, confirm everything is running:

# Check container status
docker compose ps

# Check backend logs for errors
docker compose logs backend --tail 50

# Check frontend logs
docker compose logs frontend --tail 20

Open the app in your browser and verify the changes are live.

Rolling back to a previous version

If something goes wrong, roll back to the last working commit:

# Find the commit you want to roll back to
git log --oneline

# Check out that commit
git checkout <commit-hash>

# Rebuild
docker compose up -d --build

To return to the latest version later:

git checkout main
docker compose up -d --build

Using tags for release management (recommended)

Tag stable versions before deploying to production so you always have a clean rollback point:

# On your dev machine — tag before pushing
git tag v1.1
git push origin v1.1

# On the production server — deploy a specific tag
git fetch --tags
git checkout v1.1
docker compose up -d --build

Backing up data before a major update

For significant updates it is good practice to back up your data first:

# On the production server
cp -r ./sloth-data ./sloth-data-backup-$(date +%Y%m%d)

Or as a compressed archive:

tar czf sloth-backup-$(date +%Y%m%d).tar.gz ./sloth-data

Quick reference

Task	Command
Pull latest code	`git pull`
Rebuild and restart	`docker compose up -d --build`
View running containers	`docker compose ps`
View logs	`docker compose logs -f`
Roll back to a tag	`git checkout v1.x && docker compose up -d --build`
Back up data	`cp -r ./sloth-data ./sloth-data-backup-$(date +%Y%m%d)`

3.0 KiB Raw Permalink Blame History