I built and run UserJot completely solo. No team, no contractors, just me.
UserJot is a feedback, roadmap, and changelog tool for SaaS companies. It helps product teams collect user feedback, build public roadmaps, and keep users updated on what's shipping. The infrastructure needs to handle significant traffic. In August alone we had 52,000 users hitting the platform, feedback widgets loading on customer sites, and thousands of background jobs processing.
Here's the setup I've landed on after months of iteration.
The Setup
I have three frontends, all deployed on Cloudflare Workers:
- Astro for marketing pages, blog, and docs (mostly static with minimal JavaScript)
- TanStack Start for the dashboard (server-rendered, then becomes a SPA)
- TanStack Start for public feedback boards (same approach)
Why TanStack Start? It takes the good ideas from Remix and pushes them further. Next.js has gotten bloated with too many features and abstractions. TanStack Start is simpler and more predictable.
One backend cluster:
- Docker Swarm on Hetzner (US East)
- Node.js with TypeScript
- PostgreSQL
- Caddy for reverse proxy
That's the entire infrastructure. Deployment happens through GitHub Actions that runs CI/CD and deploys to Docker Swarm. Simple, boring, works.
Why No Redis
PostgreSQL handles everything:
- Job queues using pg-boss
- Key-value storage in a JSONB table
- Pub/sub with LISTEN/NOTIFY
- Vector search with pg-vector for finding duplicate feedback
- Session storage
- Rate limiting
pg-boss has been rock solid for job queues. It's processing thousands of jobs daily: email drip campaigns, notification triggers, data syncing. It has some limitations compared to dedicated queue systems since it's built on PostgreSQL, but nothing that's actually mattered in practice.
Could Redis do some of this better? Probably. But managing one database is simpler than managing two. When you're solo, every additional service is something else that can break.
More importantly, every dependency directly affects your uptime. Two services means twice the things that can fail. Twice the things to monitor. Twice the things to back up. Twice the things to upgrade. Your availability is only as good as your weakest service. Every new service is another thing that can break at 2am.
Sure, at some point I might need Redis for caching. Or RabbitMQ for complex queue patterns. Or Kafka for event streaming. But that's a very, very long way off. And honestly? I'm not looking forward to adding those dependencies.
Single Region, Global Users
The backend runs in one location: US East.
Three things make this work globally:
- Cloudflare Argo reduces latency by routing traffic through their network
- Optimistic updates in the UI make actions feel instant
- Prefetching loads data before users click
The frontends render on Cloudflare's edge, so users get HTML from a nearby location while the data loads from the backend.
Serverless Where It Makes Sense
I use serverless for the frontends because they're stateless. They just render HTML and proxy API calls. No persistent connections, no background jobs, no state to manage.
But the backend is a traditional server. You need connection pools for PostgreSQL. You need long-running processes for job queues. You need WebSocket connections for real-time features. Serverless isn't great at these things.
This split works well:
- Frontends scale automatically on the edge
- Backend runs predictably on dedicated servers
The Trade-offs of Self-Hosting
I self-host PostgreSQL and the backend cluster. This takes more work than using managed services, but I get:
- Full control over PostgreSQL extensions and configuration
- Ability to run pg-boss, pg-vector, and other tools
- Predictable costs that don't scale with usage
- No vendor lock-in
The downside: I handle backups, updates, and monitoring myself. If you value your time more than control, managed services might be better.
When This Makes Sense
This architecture works well when:
- You're one person or a small team
- You want to own your infrastructure
- You're comfortable with PostgreSQL and Docker
- You don't need multi-region data replication
- Your features don't require complex real-time sync
It probably doesn't make sense if:
- You have a large team that needs managed services
- You need true multi-region presence
- You're not comfortable managing servers
- You need specialized databases for specific features
What I've Learned
PostgreSQL can do more than you think. Job queues, caching, pub/sub. It handles all of these reasonably well. You might not need that Redis instance yet.
Stateless frontends simplify everything. When your edge workers just render and proxy, there's no distributed state to worry about.
Single region is fine for most SaaS apps. With good caching and optimistic UI updates, users won't notice if your server is far away.
Boring technology works. Docker Swarm isn't as fancy as Kubernetes, but it's simpler and does the job.
Over-provision your servers. VMs are cheap. Having 4x the capacity you need means you never have to think about scaling during a traffic spike. Peace of mind is worth the extra $50/month.
The Reality of Maintenance
The hardest part was the initial setup. Understanding how all the pieces fit together takes time and experience. But once it's running? I spend maybe 2-3 hours per month on infrastructure.
Everything else is building features and talking to users.
Moving Forward
Will this scale forever? No, but it'll scale way further than most people think.
People seriously underestimate how much a single PostgreSQL instance can handle. Modern hardware is insanely powerful. You can scale vertically to machines with hundreds of cores and terabytes of RAM. PostgreSQL can handle millions of queries per second on the right hardware.
This setup could easily handle hundreds of thousands of active users, maybe millions, depending on your usage patterns. It might be all I ever need.
For now, and probably for years to come, PostgreSQL and a simple architecture is enough. I'm shipping features, talking to users, and growing the business. The infrastructure just works.
If you're curious about UserJot, check it out at UserJot. Always happy to chat about infrastructure decisions. Find me on Twitter/X.
Top comments (11)
the user experience feels great. congrats man 👏
🤝
last living docker swarm user 🐳
lol docker swarm is so good.
Very insightful. Thanks for sharing. Doing also many solo SaaS like Projects. Here is my tech stack (very high level).
Tool looks very useful, thanks for sharing this.
If you ever want to migrate away from docker swarm because your setup does not hold anymore. I would love to get your feedback about our platform nexaa.io
Awesome post! Thanks a lot for the insight. Could you elaborate on 2 points? 1. Your hardware stack 2. Your scaling strategy if it ever blows up so that you cannot scale with the current setup anymore. Cheers!
Astro is awesome, and I came to many of the same conclusions looking at the big picture. I have a new project where I am likely to use the database for the heavy lifting (they are good at that) and put most of the logic in a SPA front end with almost no backend. (Row-level security means you only need a backend for things like calling other APIs with a private key you can't put in the front end code.) Edge/serverless-like functions for the occasional specific need.
I am curious about your use of Docker Swarm though. I concluded Docker Swarm was best for my ELK+Redis setup at first too, but I've decided to abandon that for Postgres or another capable DB. I'm probably going to go with a managed db offered as a PaaS, probably AppWrite since I've had problems with some Supabase developer/user-hostile decisions that they won't consider. Are you only using Swarm for DB hosting, or DB+the TanStart SPA hosting? I won't need Swarm if I go with something like AppWrite managed hosting, which also bundles Auth, S3 files, Functions, and many more services needed for real apps. Like you, I plan to leverage CloudFlare for Zero Trust, Turnstile (their much-improved CAPTCHA), their Workers (functions) and maybe Realtime features. (They also support image operations and video streaming.)
From your article above, it sounds like you only really need Swarm due to the self-hosting decision? I've decided that CloudFlare or AppWrite can do a better job (especially on the networking side) and if it's all on CloudFlare, it's actually ... I don't even need an IP address. Talk about simpler, and professional, and you still get pgvector etc.
I'm really quite fond of CloudFlare as a host, and I love AppWrite for their high-level developer-friendly features, but I'm starting to think they may be mostly redundant given CloudFlare offerings. I think I could centralize everything to just CloudFlare hosting including the front end domain management and hosting. And a lot of this works with a free account for feasibility testing etc.
What's your rationale for Swarm use? Where are you hosting that?
Looks like copied front plane.so. Did you modify the existing plane project management project to make this?
Astro is awesome! 🔥🔥
Very insightful.