Last updated: June 2026 | Reading time: ~8 mins | Difficulty: Medium (agar Docker se darr nahi toh easy hai)
"My server is fine. Nothing will ever go wrong."
— Every self-hosted developer, 3 days before disaster.
The Backstory Nobody Tells You
You stayed up till 2 AM setting up Coolify. You self-hosted Plausible, Formbricks, n8n, your own Ghost blog — the whole shebang. You feel like a DevOps god. Life is good.
Then one day your VPS provider says "sorry bro, we're shutting down your region" or you accidentally run rm -rf in the wrong directory (we don't judge), or the server just... dies. No warning. No ceremony. Gone.
And then you realize — you never set up backups.
Yaar, that feeling is worse than forgetting your girlfriend's birthday.
This guide is going to make sure that never happens to you. We're going to cover the complete Coolify backup + restore process — S3 storage setup → automated backups → full database restore on a brand new server — in about 12 minutes of actual work.
Let's go. 🚀
What Even Is Coolify? (Quick Context for the New Folks)
Coolify is basically a self-hosted alternative to platforms like Vercel, Railway, or Heroku. It's your own deployment platform that runs on your server. You own everything — the apps, the databases, the traffic, the headache.
The good news? Coolify is super lightweight. Backups are literally in megabytes (1.14 MB in this case). Yes, megabytes. Not gigabytes. You can back this thing up and not even notice.
But you still need to actually do it. Toh chalo shuru karte hain.
Step 1: Set Up an S3 Storage Bucket (5 Minutes)
Before Coolify can back itself up anywhere, it needs somewhere to send those backups. Enter S3-compatible object storage.
Now, "S3" doesn't mean you have to use AWS (although you can). S3 is a protocol — a standard way that storage providers talk to each other. You can use:
- Cloudflare R2 (free egress — honestly, it's a great choice)
- AWS S3
- Backblaze B2
- DigitalOcean Spaces
- Literally anything that speaks S3
In this guide, we're going with Cloudflare R2 because it's free for small use cases and has zero egress fees. Your Coolify backups are tiny anyway.
What you need from your S3 provider:
| Field | What it is |
|---|---|
| Endpoint | The API URL of your S3 bucket |
| Region | Where the bucket lives (e.g., auto for R2) |
| Access Key | Like a username for the API |
| Secret Key | The password — keep this safe! |
| Bucket Name | Whatever you named your bucket |
In Cloudflare R2:
Go to your R2 dashboard → Create a bucket (e.g., coolify-backup) → Go to Manage API Tokens → Create a token with the right permissions (read + write on that bucket) → Copy the Access Key and Secret Key.
In Coolify:
Go to S3 Storage tab inside Coolify → Add new storage → Paste in all the details → Hit Validate Connection.
If it says ✅ — you're in business. It runs a ListObjects call under the hood to confirm everything is working.
Pro Tip: Name your S3 storage something obvious like
coolify-backup-r2so future-you doesn't spend 10 minutes wondering what that unnamed entry is for.
Step 2: Configure Automated Backups in Coolify (2 Minutes)
Now go to:
Settings → Backup
Here's what you'll see and what to do with it:
- ✅ S3 Backup Enabled — Turn this ON (obviously)
- ✅ Backup Enabled — Also ON
- S3 Storage Source — Select the bucket you just set up
- Frequency — How often do you want backups? Daily is solid for most people. You can even do multiple times per day if you're paranoid (no judgment — paranoia saves servers)
Once you configure it, you'll see an Executions section that shows your backup history. You can also trigger a manual backup right now to test it.
Do it. Seriously. Don't just set it up and assume it works — run one manual backup right now and verify it shows up in your S3 bucket.
If you see a .pgdump file appearing in your Cloudflare R2 bucket like data/coolify/backups/coolify/... — chef's kiss — your backups are working.
Step 3: The Most Important Step Nobody Warns You About — Get Your APP_KEY 🔑
Okay, this is where most tutorials just... skip this part and then your restoration fails and you're crying at 3 AM wondering what went wrong.
Listen carefully.
Coolify encrypts sensitive data (passwords, SSH keys, env vars, deployment tokens — basically everything that matters) using a secret key called the APP_KEY. This key lives in your server at:
/data/coolify/source/.env
If you restore the database without this key on the new server, all that encrypted data is unreadable. The backup is there but it's like having a locked vault with no key. Useless.
How to get your APP_KEY:
SSH into your current/old Coolify server and run:
cat /data/coolify/source/.env
You'll see something like:
APP_KEY=base64:abcXYZ123...Kne==
Copy this entire value and store it somewhere safe — a password manager, a notes app, a piece of paper in a drawer (not recommended, but better than losing it). This is your golden ticket.
⚠️ Seriously: If you lose this key AND lose your server, your backup is worthless. The data exists but you cannot decrypt it. Treat this key like your bank PIN.
Step 4: Prepare Your New Server
Got a new VPS? Fresh install of Coolify done? Perfect.
Install Coolify on the new server using the standard curl install command:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash
When it's done, go to the new server's IP in your browser. You should see the Register page (because it's a fresh install — no account yet). That's expected. Don't register yet.
The key thing here is that Coolify is running and healthy on the new server. Run:
sudo docker ps
You should see containers running, including coolify-db (the PostgreSQL container). If that's running, you're ready for the restore.
Step 5: Transfer the Backup File to the New Server
Download your .pgdump backup file from your S3 bucket (Cloudflare R2 / wherever).
Now copy it to your new server. A few ways to do this:
# Option 1: SCP (SSH Copy)
scp coolify-backup.pgdump user@new-server-ip:/home/user/
# Option 2: Download directly on the server using wget/curl
wget "https://your-r2-url/path/to/backup.pgdump"
You just need the file on the new server. Where exactly doesn't matter much — just note the path.
Step 6: Restore the Database (The Actual Magic) ✨
This is the part where your old Coolify life comes back from the dead.
Run this command on the new server (replace the path with your actual backup file location):
sudo docker exec -i coolify-db pg_restore \
--username coolify \
--verbose \
--dbname coolify \
< /path/to/your-coolify-backup.pgdump
Breaking this down in English:
-
docker exec -i coolify-db— Hum PostgreSQL container ke andar ghus rahe hain -
pg_restore— Postgres ka restore tool -
--username coolify— Database username -
--dbname coolify— Database ka naam -
< your-backup.pgdump— Aur ye hai hamara backup file which we pipe in
Don't panic when you see warnings. You'll see messages like "relation already exists" or "sequence already exists." That's normal — the fresh Coolify install already created some base tables, and the restore is just noting the conflicts. It'll still work.
Step 7: Verify It Worked — And Fix That 500 Error
Now go to your new server's IP in the browser.
Instead of the Register page, you should now see a Login page. That's the sign that the restore worked — because a fresh install shows Register, but a restored instance knows there are already accounts.
Use your old Coolify credentials (same username + password as before). They were backed up and restored too. Log in.
You should see your old projects! Your apps! Your services! Your databases! All there like nothing happened. 🎉
But wait — when you click into a project or application, you might get a 500 Internal Server Error. Don't panic. This is the APP_KEY issue we warned you about earlier.
Step 8: The Final Fix — APP_PREVIOUS_KEYS
Here's what's happening: your new Coolify instance has a new APP_KEY (generated during fresh install). But all your database data is encrypted with the old APP_KEY. Coolify is like "I can't read this, what is this gibberish?"
The fix: tell Coolify about the old key.
Step-by-step:
a) Navigate to the .env file:
# If you get permission denied, fix it first:
sudo chown -R $USER /data/coolify
cd /data/coolify/source
b) Edit the .env file:
nano .env
c) Add this line (with the APP_KEY you saved from the old server):
APP_PREVIOUS_KEYS=base64:your-old-app-key-that-ends-with-Kne==
This is Coolify's way of saying "hey, if you can't decrypt something with the current key, try this old one." Smart system, honestly.
d) Save and exit: Ctrl+X → Y → Enter
e) Reinstall/restart Coolify:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash
Wait for it to restart all containers...
Step 9: The Happy Ending 🎊
Go back to your browser and refresh. Click on that application that was throwing 500 errors.
It works.
Go check:
- ✅ Your projects are there
- ✅ Your credentials work
- ✅ Your deployment history is there
- ✅ Your logs are there
- ✅ Your S3 storages are there
- ✅ Everything is exactly where you left it
That's it. That's the whole thing. Aapka data safe hai. Aapki neend safe hai.
Quick Recap — The TL;DR Cheatsheet
1. Set up S3 storage in Coolify (Cloudflare R2 is free + great)
2. Enable automated backups → Settings → Backup
3. 🔑 SAVE YOUR APP_KEY from /data/coolify/source/.env
4. New server → Install fresh Coolify
5. Transfer backup .pgdump file to new server
6. Restore: docker exec -i coolify-db pg_restore --username coolify --dbname coolify < backup.pgdump
7. Login with old credentials (they're restored too!)
8. If 500 error → Add APP_PREVIOUS_KEYS to .env → Reinstall Coolify
9. Profit 🚀
Lessons Learned (aka Don't Be That Guy)
Here's what separates "oh no" developers from "oh yeah" developers:
❌ Don't: Wait for your server to die before thinking about backups.
✅ Do: Set up automated backups before you need them.
❌ Don't: Forget to save your APP_KEY somewhere safe.
✅ Do: Save it in a password manager today.
❌ Don't: Assume your backup is working just because you configured it.
✅ Do: Run a manual backup and verify it appeared in S3.
Final Thoughts
Self-hosting is powerful. It gives you control, privacy, and cost savings that hosted platforms can't match. But with great power comes great responsibility — and that responsibility is mostly just "please run backups."
Coolify's backup system is honestly well-designed. The backups are tiny (~1 MB), the S3 integration is clean, and the restore process — while slightly tricky with the APP_KEY stuff — works perfectly once you know what you're doing.
Iss guide ke baad you should have:
- Automated backups running to S3
- Your APP_KEY saved safely
- The confidence to move your Coolify instance to any server, anytime
Go set up your backups. Right now. Don't finish reading this and forget. Seriously. Jao. Do it.
Found this helpful? Share it with your self-hosting friends who also haven't set up backups yet. They need this more than you think. 😅
Tags: coolify, self-hosted, backup, restore, cloudflare r2, s3 backup, postgresql restore, docker, vps migration, devops
Top comments (0)