# 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:

```bash
# 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:

```bash
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

```bash
# 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:

```bash
# 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:

```bash
# 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:

```bash
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:

```bash
# 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:

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

Or as a compressed archive:

```bash
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)` |