My one-man-SaaS setup:<p>- Static frontend hosted on Netlify (free unlimited scale)<p>- Backend server on Google App Engine (connecting to Gcloud storage and managed DB via magic)<p>I realize I'm opening myself up to vendor lock-in and increased costs down the road (if I even get that far), but I've wrangled enough Docker/k8s/Ingress setups in the past to know it's just not worth the time and effort for a non-master.
Anthony - if you're reading this, thank you!! To arrive at this architecture takes 100s if not 100s of hours, and to share it with the community is dang inspiring.<p>I was feeling a bit down on my projects, but this has me amped up seeing how the ultimate goal of working on features rather than deployment is possible, and very real!<p>Best of luck with Panelbear!
The author almost seems to apologize for having a django monolith.<p>But it's worth realising that one purpose of code organisation in larger companies is to mirror the team organisation. That's a constraint on code that can interfere with the best technical architecture.<p>You can do better with a monolith in a one-man team!
How do you start learning this breadth of software engineering? I consider myself good in the python / django space, but where do I start with learning these infrastructure technologies? I find that I use them once or twice periodically, and then don't touch them for so long, so I forget much of what I have learned.
My one-person SaaS architecture with over 250k users:<p>* Flask + Flask-Login + Flask-SQLAlchemy [1]<p>* uWSGI app servers [2]<p>* Nginx web servers [3]<p>* Dramatiq/Celery with RabbitMQ for background tasks<p>* Combination of Postgres, S3, and DigitalOcean Spaces for storing customer data [4]<p>* SSDB (disk-based Redis) for caching, global locks, rate limiting, queues and counters used in application logic, etc [5]<p>I like how OP shows the service providers he uses, and why he decides not to self-host those parts of his infra. Also, there's a large up front cost involved for any stack (Rails, Django, k8s). I'd be interested in a more detailed writeup with configs, to try out OP's auto-scaling setup. My configs are linked in the gist below [2] for my non-auto-scaling Flask setup.<p>I spend about $4,000/mo on infra costs. S3 is $400/mo, Mailgun $600/mo, and DigitalOcean is $3,000/mo. Our scale/server load might be different, but I'm still interested in what the costs would be with your setup.<p>[1] <a href="https://wakatime.com/blog/33-flask-part-2-building-a-restful-api" rel="nofollow">https://wakatime.com/blog/33-flask-part-2-building-a-restful...</a><p>[2] <a href="https://gist.github.com/alanhamlett/ac34e683efec731990a75ab69d5699a1" rel="nofollow">https://gist.github.com/alanhamlett/ac34e683efec731990a75ab6...</a><p>[3] <a href="https://wakatime.com/blog/23-how-to-scale-ssl-with-haproxy-and-nginx" rel="nofollow">https://wakatime.com/blog/23-how-to-scale-ssl-with-haproxy-a...</a><p>[4] <a href="https://wakatime.com/blog/46-latency-of-digitalocean-spaces-vs-aws-s3" rel="nofollow">https://wakatime.com/blog/46-latency-of-digitalocean-spaces-...</a><p>[5] <a href="https://wakatime.com/blog/45-using-a-diskbased-redis-clone-to-reduce-aws-s3-bill" rel="nofollow">https://wakatime.com/blog/45-using-a-diskbased-redis-clone-t...</a>
I'd argue that just about every infrastructure that looks like this benefits from Kubernetes (that you're not setting up and managing), and that's <i>a lot</i> of them. The biggest problem is that not enough people have boiled down Kubernetes enough to look like heroku yet. Google Cloud Run is possibly the best example of what Kubernetes can look like/run like -- it runs on (probably a relatively heavily modified) KNative, a project that runs <i>on top</i> of kubernetes.<p>The "point" of Kubernetes is to drop the difficulty of building a service like Cloud Run to zero. It drops the cost of building a Heroku down to zero. I'd bet my bottom dollar that fly.io and render are running on Kubernetes (maybe they mentioned it somewhere already and I just missed it). With the right cluster set up, building one of those platforms (or others that I won't mention) is <i>almost</i> as simple as setting up stripe checkout and writing a web interface to turn form fields into JSON fields and send them to a kubernetes cluster (possibly with hard multi-tenancy! not to get too into it, but you can literally provision kubernetes clusters from kubernetes clusters, ephemeral or otherwise).<p>No other tool in the devops world except for maybe the initial orchestrator wave (ansible/puppet/salt/chef) has been this much of a force multiplier. Ok, maybe that's hyperbole, but if adhoc-bash-scripts->ansible is 1->2, Ansible->Kubernetes is similarly 1->2, especially if you consider baked in cloud provider support/innovation.<p>But here's the secret -- perversely, I'm happy deep down that everyone thinks k8s is too complicated/is a buzzword/isn't worth the effort. All it means to me is that I'm still ahead of the curve.
I am also a one-man SaaS (though not a successful one). The following tends to be my stack (on Google Cloud, if you will):<p>- Cloud Run (serverless containers)<p>- Cloud SQL (via proxy)<p>- Cloud Monitoring & Logging (formerly Stackdriver)<p>- Compute Engine (if necessary, e.g. websockets)<p>- Cloud Build for GitOps (deploy on push)<p>It's clean and simple (to me). Billing is in one place, nicely separated by projects. Monitoring & Logging is already built in. No need to span multiple dev SaaS tools. So far managed to avoid Redis caching because Golang + Postgres is fast enough, so far. But if you need Redis you can DIY on Compute Engine or try Cloud Memorystore (configure the memory to a low amount for cost savings).<p>Google Cloud drawbacks: Additional charges necessary to connect Cloud Run to VPC (via proxy instances). Load balancing on GCP ain't cheap ($18/month, though to a larger enterprise that is a rounding error). But in my setup I didn't need these things.<p>As shown above, I have heavily optimized for cost and simplicity in my setup.
Good article. My comment might be off topic in which case, please ignore.<p>If you have a one-person SaaS company, how do you get past customers’ resistance to a single point of failure, namely you?<p>Do you pretend you’re not just one person? Do you only have customers who could handle losing the service when you, say, run away to meditate on the mountaintop? (Or get run over by a beer truck, or whatever.) Is there some non-obvious solution?<p>And — back on topic — is the architecture part of that sales pitch? “I’m just one dude, but look how simple this is, it can run itself if I am devoured by mice!”
This is really well done.<p>A suggestion, hopefully helpful: a better approach to securing your admin console than simply layering 2FA onto it would be to expose it to a private WireGuard network. One very easy way to do that is with Tailscale, which will hook up to your GSuite authentication --- Google's 2FA stack will be far better than anything you'd likely build on your own.<p>Tailscale is <i>disgustingly</i> simple to set up. If you're a product person, it's actually upsetting how easy they've made it to get set up.
An important distinction here is that PanelBear (OP's One Man SAAS) is something I would define as an "analytics" SAAS and as such has requirements that are way above what a typical CRUD SaaS might have.<p>That's not to take anything away from the excellent writeup, but more so that someone who is thinking about starting a SaaS maybe doesn't jump to the conclusion of "I should go learn Kubernetes".
This is probably not the best place to ask this question, but as a solo founder or just to reduce costs/time are there some standard free software packages that are used when creating sites? For example most sites need a user sign up mechaism, a authN and authX mechanism to gate access to different pages. Are there open source projects that provide this? Or do site owners develop these from scratch every time?
My infrastructure is $2,800/year.<p>There are two Servers load balanced with DNS.<p>Each Server has 3 jails (Nginx, App, DB) and 2 NICs<p>The internal NIC is for replicating the DB, and for the App Servers to target the Primary one.<p>Diagram and Configs:
<a href="https://blog.uidrafter.com/engineering/freebsd-jails-network-setup" rel="nofollow">https://blog.uidrafter.com/engineering/freebsd-jails-network...</a>
Good on them. I wish I could use K8 as effectively as the author, it is an incredibly overwhelming list and an impressive range of knowledge.<p>In my situation I am finding the lack of consistent environment a reoccuring issue, the developer environment does not match production. However I kept it simple with Google App Engine Standard and Flex environments, I found the deployment process simple and was enough for me (at the time) - however I am finding we are going to step into dockerland; however I feel like it is very over my head!
I always feel like these write-ups about SaaS's are written by people who make SaaS's for other SaaS's. Application monitoring, email marketing, etc.
In the beginning my startup only had 2 people. A designer (my friend) and me (a developer).<p>For our frontend we used Webflow. My friend was able to create the entire marketting site, and all the app UI's without needing help from me. Webflow is an awesome tool for that sort of thing.<p>For the backend, I built a simple Node/Express API and hosted via Heroku.<p>To this day, everything is still running fine and the API is processing roughly 200 million requests a month. The total cost to host that on heroku is $50/mo.<p>You can definitely have a simple stack but have it be highly scaleable!
I really enjoy reading these to learn the infra behind one man bands.<p>Another good read is Wenbin from Listen notes. <a href="https://www.listennotes.com/blog/how-i-accidentally-built-a-podcast-api-business-46/" rel="nofollow">https://www.listennotes.com/blog/how-i-accidentally-built-a-...</a>
Super interesting! Definitely feels like a lot of fairly low-level tech to have to deal with for a one-person company, but I guess that doesn't surprise me any more :)
For my typing SaaS, I found firebase hosting/realtime DB a ginormous time saver.<p>And since it hasn't taken off (and probably won't ever), it just costs me a pennies a month since I'm under their free limits, plus the domain.
I was under the impression that Kubernetes was a complicated beast not meant for small teams / startups. What is the value of it in <i>this</i> monolith environment? Is the key to using it in a startup context to use it as a basic monolith auto-scaling orchestrator but no more than that? If you or anyone else here can comment about how to use Kubernetes strategically without falling into an unnecessary over-engineering rabbit hole, I'm willing to learn from you.<p>Regarding the rate limiting, you're load balancing into nginx services that you've configured to limit requests. Are they synchronizing rate limiting state? I can't seem to find nginx documentation supporting this. What value is there in this style of rate limiting, considering User X can send a sequence of requests into a load balancer that routes them to nginx boxes A, B, and C? The big picture that 3 requests were processed for user X gets lost. Your endpoint-level rate limiting, however, may potentially be achieving the synchronized rates if the redis servers in a cluster are synchronizing. I guess I'm asking about the strategy of using multiple lines of rate limiting defense. Is nginx-level rate limiting primarily for denial of service?<p>The horizontal autoscaler should be based on throughput rather than hardware consumption, shouldn't it? If the req/sec goes below a threshold, spawn a new service. Can anyone comment?
> From a technical point of view, this SaaS processes a large amount of requests per second from anywhere in the world, and stores the data in an efficient format for real time querying.<p>That is the closes thing to a number of requests I could find. So this architecture, no matter how solid, is somewhere between „way to large“ and „matches perfect“.<p>It seems like a solid breakdown on how to deploy your services to k8s and how to properly do CD deployments. But it does never mention whether it actually makes sense at the scale he actually has.
My one-man-SaaS setup:<p>- A single VPS server to host the app. I love DigitalOcean.<p>- A single docker-compose file to bring up the entire stack containing the front-end, the back-end and the database.<p>- Caddy for automatic SSL certificates and proxying.<p>- JavaScript/TypeScript for building stuff.<p>- Cloudflare For DNS
A lot of people are going to jump on the "he used k8s and he doesn't even work at Google scale!" part of this writeup, but I think it's a perfect demonstration of the concept of innovation tokens [1]. He admits in TFA that clickhouse was the only new piece of tech in his stack, and he was already familiar with k8s et al - so he's able to focus on actually building the products he wants. I could see somebody unfamiliar with k8s (but very familiar with all other pieces of tech in the system they want to build) being able to learn it as part of a side project, if it's the <i>only</i> new thing. Where the wheels come off is when you've never touched k8s, postgres, aws, rust, graphQL or vue - and you try to mash them all together in one ambitious project.<p>[1] <a href="https://mcfunley.com/choose-boring-technology" rel="nofollow">https://mcfunley.com/choose-boring-technology</a>
As a one person company I find it not just helpful but a core principle to minimize the number of stacks/tools/services being used. Overhead of task switching and learning curves.
This goes against the HN trope that "you don't need Kubernetes unless you are Google-size".<p>It turns out Kubernetes is actually perfect for small teams as it solves many hard operational issues, allowing you to focus on the important part of the stack: the application.<p>The key is to stick to a simple setup (try not to mess with networking config) and use a managed offering such as GKE. We may need a Kubernetes, The Good Parts guide.
My one man SaaS setup: t4g.micro (Free Trial) on AWS Ec2 - one mod_perl module + a bunch of python/perl scripts. ( <a href="https://poidata.xyz" rel="nofollow">https://poidata.xyz</a> ). Startup costs so far=$1 (domain registration).
Reminds me of Listen Notes: <a href="https://www.listennotes.com/blog/the-boring-technology-behind-a-one-person-23/" rel="nofollow">https://www.listennotes.com/blog/the-boring-technology-behin...</a>
(Render founder) This is incredible work, and underscores the reason Render exists and is recommended by OP. Everything mentioned in the post is baked into Render already:<p>* Automatic DNS, SSL, and Load Balancing<p>* Automated rollouts and rollbacks<p>* Health checks and zero downtime deploys (let it crash)<p>* Horizontal autoscaling (in early access!)<p>* Application data caching (one-click ClickHouse and Redis)<p>* Built-in cron jobs<p>* Zero-config secrets and environment variable management<p>* Managed PostgreSQL<p>* DNS-based service discovery with private networking<p>* Infrastructure-as-Code<p>* Native logging and monitoring and 3rd-party integrations (LogDNA, Datadog, more coming this month!)<p>* Slack notifications<p>More at <a href="https://render.com" rel="nofollow">https://render.com</a>.
Cool write-up. I am a K8s hater, but I can see how this can work well for small projects with 1 developer. EKS definitely takes a lot of the maintenance headache, but there'll still be some down the line.
Interesting post. I would advice people against running a kubernetes / docker setup if you don't know it well. It's quite complicated and most small companies don't really need it.<p>As the author say, he already got a lot of experience of it so it worked out great for him but it is probably easier just to install the tech needed for a small company.<p>Unless you have something very special going on, the dependencies (like databases) are probably not going to be that many.
I was just reading the beginning of Arvid Kahl's Zero to Sold. He recommends using a tech stack that you already know and have lots of muscle memory with. I couldn't agree with him more. [1]<p>This tech stack looks over-engineered upon first glance, but I don't know much about the author or his product.<p>I use Kubernetes a fair bit whilst developing OpenFaaS and teaching people about K3s, but there is a whole world of development teams who aren't prepared to consider it as an option. One of the reasons we created "faasd" [2] (single-node OpenFaaS) was to help people who just wanted to run some code, but didn't want to take "Kubernetes mastery 101"<p>For a small app using a managed service like Cloud Run plus some cloud storage should get you very far. I saw that Heroku is still popular with the indie community, with the author of Bannerbear getting a lot of value from the managed platform.<p>[1] <a href="https://thebootstrappedfounder.com/" rel="nofollow">https://thebootstrappedfounder.com/</a>
[2] <a href="https://github.com/openfaas/faasd" rel="nofollow">https://github.com/openfaas/faasd</a>
My one-person SaaS architecture:<p>It’s a Rails monolith deployed on Heroku.<p>I’d rather have the time to build new features for my user base than spend it learning how to use k8s or wrangling AWS through its abysmal console website.
One thing I noticed a lot with indie or "one-man" startups is they make ample use of other SaaS tooling, often lesser heard of or known ones as well.<p>I am not sure what the right answer is, but I at least appreciate that there founders out there willing to give the little-er shops a chance. A healthy ecosystem with competition is good for the most amount of people.
I hate to give homework to other people but I suggest you expand this out: udemy class, booklet, or a series of blog posts with tasteful ads.<p>Ideally, you would get it to the point where a newbie can use it as a reference.
Great write up! Reminded me of the "The boring technology behind a one-person Internet company" [0] and the HN discussion [1].
[0] <a href="https://www.listennotes.com/blog/the-boring-technology-behind-a-one-person-23/" rel="nofollow">https://www.listennotes.com/blog/the-boring-technology-behin...</a>
[1] <a href="https://news.ycombinator.com/item?id=20985875" rel="nofollow">https://news.ycombinator.com/item?id=20985875</a>
I run a one-person SaaS company supporting three products. One is an iOS and Android all-local storage app so that costs me nothing to run. I have two projects running on Django sharing the same RDS DB. I can support two apps with just a single EC2 each. One runs docker containers. The other I did not dockerize yet. For me, the total costs are about $40/month. I have looked at Netlify and other “easy options” but they double or more my costs due to their costly basic tiers.
The secret management seems overly complex, why not use <a href="https://aws.amazon.com/blogs/containers/aws-secrets-controller-poc/" rel="nofollow">https://aws.amazon.com/blogs/containers/aws-secrets-controll...</a> or <a href="https://kubernetes.io/docs/concepts/configuration/secret/" rel="nofollow">https://kubernetes.io/docs/concepts/configuration/secret/</a> ?
Thanks for a great post! It was super detailed and I loved reading it. I had a quick question about your pg setup. You mentioned that you use EBS for your persistence storage, which is locked by zone . You can't have an EC2 instance in Zone 1 mount a storage in Zone 3. Does this cause issues with your db? Especially as you have HPA and ClusterAutoscaler, your k8s nodes could be spun up in Zone 1 for pg autoscaling but your data is in Zone 3.
This looks solid. And k8s makes total sense, since you are avoiding vendor lock-in.<p>I'm just wondering why you don't also run your managed services in k8s?
Panelbear's homepage:<p><a href="https://panelbear.com/" rel="nofollow">https://panelbear.com/</a><p>>"Web Performance and Traffic Insights<p>From the small stuff to the big picture, Panelbear gives you the insights you need while respecting the privacy of your visitors. It's simple, and fast."<p>Price is based on client websites' page views per month, with free tier to 5K page views.
I have done with before, ran and one man b2b saas platform with 30clients from around the world. Infrastructure was the easiest part. We where processing roughly 100million messages a day, about 5 nodes. Monitoring was good, application performance tracking was good. Business ran for close to 7 years, making about 1.3mill a year on an average year.
I don't have the startup part yet but here's my one-person stack with Postgres, Node and React deployed on AWS with CDK using RDS, Lambda, S3 and Cloudfront. It's 100% in the free tier.<p><a href="https://github.com/cadbox1/prawn-stack" rel="nofollow">https://github.com/cadbox1/prawn-stack</a>
I created a similar post a while back for the GRANTS stack. ( GraphQL, React, ArangoDB, Nodejs, Typescript, Serverless ) <a href="https://github.com/mikestaub/slack-lunch-club" rel="nofollow">https://github.com/mikestaub/slack-lunch-club</a>
Nice read. I haven't seen any references to Ansible or similar tools. For the ones who know: given the architecture described in the article, does Ansible fit in the picture? I don't know a lot of k8s but I wonder how VMs are provisioned (e.g., how docker is installed?)
Hey great post! Thanks for sharing so many details. Just one question: how do you approach profiling in production? Specifically in those cases where copying whatever slice of data from the prod DB would be too much to handle.
Digital Ocean / Vultr + Ubuntu droplets solve everything for us. We slap a sucuri in front of it, or for cheaper projects Cloudflare. I can't understand the complexity people come up with like this.
I'm currently using zappa and lambda for supporting about 25 b2b users. It's a django / react application and I use cloudwatch for scheduled cron jobs. My overall cost is <$20 a month.
It's probably fine, but reading about a single Postgres container in a Kubernetes cluster with backups to S3 gives me sweaty palms. I hope the author has fully tested their disaster recovery plan.
If you're using Stripe for billing how do you handle tax compliance, specifically related to the VAT requirements in each EU country as well as sales tax requirements in each US state?
It's a great writeup, I just find it weird that the author runs his "privacy-focused" analytics service on AWS and Cloudflare. From a GDPR perspective it's not even clear if this is lawful (Schrems-II), and there are some good alternative cloud services available in the EU (e.g. Hetzner or OVH). Also, Cloudflare still sets the __cf* cookie on every request, so it's not really cookieless tracking (I'm aware that Cloudflare is planning to get rid off this cookie though).<p>Edit: Maybe the downvoters can explain what they're disagreeing with?
One person forum platform setup:<p>-Inmotion shared hosting (some $10/mo fixed)<p>-PHP (codeigniter framework) with MySQL<p>Not very proud in the age of Cloud, but I can’t deal with all the complexities. Command line scares me (which seems to be the requirement these days for any development). Now I have a simple ftp folder mapped directly in VS Code.
Thanks for sharing, very detailed. i might use some ideas for my own SaaS <a href="https://simpleops.io/" rel="nofollow">https://simpleops.io/</a>