The Problem That Shouldn’t Exist (But Does)
Picture this: You’ve built a beautiful side project. Clean API, responsive frontend, PostgreSQL database humming along nicely on Supabase’s generous free tier. You deploy it, share it with friends, then move on to your next idea.
Seven days later, your project is dead. Not crashed. Not broken. Just… asleep.
This is the reality of Supabase’s free tier: 7 days of database inactivity = automatic project pause. It’s a reasonable policy for resource management, but it’s a headache for developers managing multiple projects, demo environments, or anything that doesn’t have consistent traffic.
Sure, you can manually reactivate projects from the dashboard. But if you’re like me and have 5+ side projects running simultaneously, that’s a game of whack-a-mole you didn’t sign up for.
Why Not Just Switch to Firebase?
Fair question. Let me break down the landscape:
Firebase Spark (Free)
- ✅ No inactivity policy (this is huge)
- ✅ Mature ecosystem, great docs
- ❌ NoSQL only (goodbye complex queries)
- ❌ Cloud Functions can get expensive fast
- ❌ Vendor lock-in is real
AWS Free Tier
- ✅ Maximum flexibility and power
- ✅ Production-grade infrastructure
- ❌ Steep learning curve (configuration alone takes hours)
- ❌ 12-month limit on free tier
- ❌ Easy to accidentally rack up charges
Supabase Free Tier
- ✅ PostgreSQL with 500MB storage
- ✅ Auto-generated REST APIs
- ✅ Built-in real-time subscriptions
- ✅ Open source (self-hosting possible)
- ✅ Developer experience is phenomenal
- ❌ That 7-day pause policy
For rapid prototyping with relational data, Supabase is unbeatable. The problem is simple:
// This is literally all you need
const { data } = await supabase
.from('posts')
.select('*')
.eq('user_id', userId);
I wasn’t going to abandon this developer experience over an automation problem. So I built the automation.
Existing Solutions (And Why They Weren’t Enough)
The developer community had already tackled this. Projects like supabase-inactive-fix on GitHub use a straightforward approach: periodically insert data into the database to simulate activity.
Smart. But after using these solutions, I noticed gaps:
- Predictable patterns: Always inserting the same number of rows looked robotic
- Data bloat: No cleanup mechanism for dummy data
- Deployment complexity: Building Docker images for every code change
- Monitoring blindness: No visibility into what’s actually happening
These weren’t deal-breakers, but they were opportunities for improvement.
Building SupabaseZombi: Technical Architecture
The name came from the zombie metaphor – something that keeps moving, keeps active, refuses to die. Perfect for a keep-alive service.
Core Innovation #1: Dynamic Data Patterns
Instead of inserting a fixed number of rows, SupabaseZombi randomizes its behavior:
# Insert 1-10 rows randomly
insert_count = random.randint(1, 10)
# Auto-cleanup when threshold exceeded
if current_count > 50:
delete_count = current_count - 30
# Delete oldest records first
Why this matters:
- Mimics natural database activity patterns
- Useful for realistic system testing
- Maintains database efficiency (critical with 500MB limit)
- No manual cleanup required
The 50/30 threshold was chosen deliberately – enough data to look organic, but small enough to be negligible in your database space.
Core Innovation #2: Multi-Project Configuration
Early versions used environment variables:
SUPABASE_URL_1=...
SUPABASE_KEY_1=...
SUPABASE_URL_2=...
SUPABASE_KEY_2=...
This doesn’t scale. Managing 5+ projects becomes a configuration nightmare.
The JSON solution:
[
{
"name": "Production API",
"supabase_url": "https://xxx.supabase.co",
"supabase_key": "your-key",
"table_name": "keep_alive"
},
{
"name": "Staging Environment",
"supabase_url": "https://yyy.supabase.co",
"supabase_key_env": "SUPABASE_KEY_STAGING",
"table_name": "keep_alive"
}
]
Benefits:
- Unlimited project support
- Structured and readable
- Supports both direct values and environment variable references
- Version control friendly (with proper .gitignore)
Core Innovation #3: Zero-Build Docker Strategy
Traditional Docker workflow:
- Write Dockerfile
- Build image (5+ minutes)
- Run container
- Change code? Rebuild everything.
SupabaseZombi’s approach:
docker run -d \
-v $(pwd)/main_standalone.py:/app/main.py:ro \
-v $(pwd)/config.json:/app/config.json:ro \
python:3.11-slim \
sh -c "pip install supabase requests && python /app/main.py"
By mounting the source code as volumes, we eliminate the build step entirely:
- ✅ Instant deployment
- ✅ Fast iteration (just restart container)
- ✅ No Dockerfile maintenance
- ✅ Using official Python images (better security)
Core Innovation #4: Structured Logging
Operations visibility is critical when automating infrastructure:
2025-10-30 09:00:00 - INFO - == Run start (2 servers)
2025-10-30 09:00:00 - INFO - = Server #1: Production API
2025-10-30 09:00:01 - INFO - ✓ SUCCESS | #15 rows | Inserted: 7 | Deleted: 0
2025-10-30 09:00:01 - INFO - = Server #2: Staging Environment
2025-10-30 09:00:02 - INFO - ✓ SUCCESS | #53 rows | Inserted: 5 | Deleted: 23
2025-10-30 09:00:02 - INFO - == Next run: 2025-10-31 09:00:02
Every log entry includes:
- Timestamp for audit trails
- Success/failure status
- Operational statistics
- Next scheduled run
When something breaks at 3 AM, these logs make debugging trivial.
Core Innovation #5: Real-Time Notifications
Telegram Bot API integration provides instant feedback:
Success notifications:
✅ SupabaseZombi Run Complete
• Production API: +7 rows, -0 old
• Staging: +5 rows, -23 old
Next run: 2025-10-31 09:00
Failure alerts:
❌ SupabaseZombi Error
Server: Production API
Error: Connection timeout
Check logs for details
You don’t need to SSH into your server or check Docker logs. Issues come to you.
The Scheduling Decision
Why 24-hour intervals?
- Safety margin: 7-day policy means we have 6+ days of buffer
- Resource efficiency: More frequent pings waste resources
- Policy compliance: Respects Supabase’s intent
Running every hour would work, but it misses the point. We’re simulating genuine project activity, not gaming a system.
Getting Started in 60 Seconds
# 1. Clone the repository
git clone https://github.com/shsm0520/supabasezombi.git
cd supabasezombi
# 2. Configure your projects
cp config.json.example config.json
# Edit config.json with your Supabase credentials
# 3. Launch with Docker Compose
docker-compose up -d
# 4. Verify it's working
docker-compose logs -f
That’s it. Your projects will stay active automatically.
Production Results
After running SupabaseZombi across multiple projects for several months:
Quantitative wins:
- ✅ Zero manual reactivations required
- ✅ 5+ projects managed from single container
- ✅ Database storage remains under 1% usage
- ✅ 100% uptime for monitored projects
Qualitative improvements:
- ✅ Mental load reduced – one less thing to remember
- ✅ Demo environments always ready for client presentations
- ✅ Side projects accessible whenever inspiration strikes
What’s Next: Community-Driven Roadmap
Confirmed (In Development) ✅
1. Flexible Scheduling
{
"schedule": {
"interval_hours": 12, // Run every 12 hours
"run_at": "09:00" // Or run at specific time
}
}
Users have different needs. Some prefer more frequent checks, others want minimal resource usage. Customizable scheduling addresses both.
2. Multi-Channel Notifications
Currently Telegram-only, but Slack and Discord integrations are coming. Enterprise teams often use Slack, while developer communities prefer Discord.
Under Consideration 🤔
3. Web Dashboard
localhost:8080 →
• Project list with status indicators
• Execution history graphs
• GUI-based configuration
• Manual run triggers
A web UI would significantly improve UX, but also increases project complexity. Waiting for community feedback to gauge actual demand.
4. Health Check API
{
"status": "healthy",
"last_run": "2025-10-31 09:00:00",
"next_run": "2025-11-01 09:00:00",
"databases": {
"total": 3,
"healthy": 3,
"failed": 0
}
}
For integration with external monitoring systems (Datadog, New Relic, etc.). Security considerations (authentication, firewall rules) need thorough review first.
5. Intelligent Retry Logic
Exponential backoff for transient failures:
- Network hiccups
- Supabase maintenance windows
- Rate limiting scenarios
6. Analytics & Metrics
- Execution history and success rates
- Per-database performance metrics
- Average response times
- Data growth trends
Long-term, integration with standard monitoring tools (Grafana, Prometheus) is on the radar.
Long-Term Vision ⏸️
7. Cross-Platform GUI Client
Electron-based desktop app for non-technical users. Currently, the Docker solution is simple enough that this may not be necessary.
8. Multiple Keep-Alive Strategies
- Lightweight API calls (no data insertion)
- Periodic Edge Function triggers
- Storage-level activity
Each strategy has trade-offs. Offering user choice is appealing, but we must preserve the project’s core value: simplicity.
9. SaaS Platform
“SupabaseZombi.io” – a hosted service where users just sign up and enter their Supabase credentials. No Docker, no configuration files.
This is attractive, but introduces complexity:
- Infrastructure costs
- Privacy considerations (storing user credentials)
- Sustainable business model
- Legal compliance
On hold pending further research.
Open Source Philosophy
SupabaseZombi is MIT licensed – use it, modify it, distribute it freely. The project thrives on community feedback.
Want to contribute?
- 🐛 Found a bug? Open an issue
- 💡 Have an idea? Start a discussion
- 🔧 Want to code? Pull requests welcome
The roadmap above isn’t set in stone. Community input shapes priority.
Closing Thoughts
Supabase’s 7-day inactivity policy is reasonable from a resource management perspective. But for developers managing multiple projects, it’s a tax on attention.
SupabaseZombi removes that tax. It’s not about circumventing policy – it’s about automating compliance. Your projects maintain genuine activity without manual intervention.
Technical achievements:
- Automated repetitive manual work
- Enabled multi-project orchestration
- Optimized resource usage
- Provided operational visibility
- Delivered platform-independent deployment
But most importantly: It gave me back my mental space. No more Sunday evening logins to reactivate projects. No more “wait, was that demo environment paused?” moments before client calls.
If you’re facing similar challenges, give SupabaseZombi a try. If you have ideas for improvement, let’s discuss them.
👉 GitHub Repository: https://github.com/shsm0520/supabasezombi
Disclaimer
This project complies with Supabase’s terms of service by simulating normal database activity. Users are solely responsible for their Supabase projects. This tool is provided “as-is” without warranty.
Built with ❤️ for developers who have better things to do than babysit free tier projects.
