let me tell you a story about infrastructure. no, wait. don’t leave. i promise this won’t be boring.

so here’s the scene: it’s just me, a moderately capable credit card, and this dream of building a saas product called mojodojo. i’ve got the code. i’ve got the product. now i need somewhere to put the damn thing so people can actually use it.

the infrastructure paradox

the problem with building infrastructure as a solo founder is this maddening paradox:

• you need something reliable enough for customers to trust
• you need it cheap enough that you don’t go broke before you have customers
• you need it simple enough that you can maintain it alone
• you need it robust enough to scale when you finally get traction

it’s like being asked to build a ferrari on a toyota corolla budget, with only the tools in your kitchen drawer, but make sure it can transform into a bus when needed. (and yes, i actually drive a corolla in real life, so i know exactly what i’m talking about here).

the great cloud provider trap

before i dive into my solution, let’s talk about the elephant in the room: the major cloud providers.

aws, gcp, azure - they all offer these incredibly attractive “get started” packages. free credits for startups. fancy dashboards. hundreds of services that promise to solve every problem you could possibly have.

and that, my friends, is the trap.

the cloud honeymoon phase

it starts innocently enough. you get those sweet startup credits, maybe $5,000 or $10,000 of free cloud services. you spin up managed databases, managed kubernetes, load balancers, cdn services, and a dozen other things with names containing either “lambda” or “serverless.”

you tell yourself, “this is amazing! i don’t have to worry about any infrastructure!”

the serverless trap within the trap

and then there’s serverless - the trap within the trap. oh boy, where do i even start with this one?

serverless functions (aws lambda, azure functions, gcp cloud functions) seem like the ultimate solution at first:

• “pay only for what you use!”
• “infinite scaling!”
• “no servers to manage!”

on paper, it’s genius. in practice? complete disaster for many businesses once they grow. here’s why:

1. unpredictable costs: once your traffic grows, your costs don’t scale linearly - they explode
2. cold start problems: function cold starts create inconsistent performance your users will notice
3. debugging nightmare: try figuring out what’s wrong with a distributed system of 250 functions
4. tooling limitations: local development is painful at best, impossible at worst
5. vendor lock-in: every provider implements serverless differently

it got so bad that even amazon themselves migrated prime video away from serverless to regular servers, which reduced their costs by 90%. yes, the company that invented lambda decided it didn’t make financial sense for their own flagship video product.

serverless has its place for genuinely spiky workloads with long idle periods. but for steady-state applications? it’s a financial disaster waiting to happen.

then the bill comes

fast forward six months. your startup credits are running out, but hey, you’ve got some customers now! you’re making maybe $2,000 a month. you’re growing!

then you get your first real cloud bill: $3,500.

wait, what? how did that happen?

• that managed database that was “only” $50/month now costs $300 because your data grew
• those serverless functions are getting hammered more than expected
• your kubernetes cluster that seemed so reasonably priced is suddenly costing $800/month
• data transfer fees alone are $400

and the worst part? you’re completely locked in. your entire architecture is built on provider-specific services that would take months to migrate away from.

i’ve seen startups brought to their knees by cloud bills. i’ve watched founders forced to raise money not for growth, but just to pay aws.

the cloud provider business model

these companies aren’t evil, but let’s be clear about their business model: they want you completely dependent on their ecosystem, using as many of their services as possible, locked in for life.

it’s like a drug dealer: the first hit is free, but once you’re hooked, the price goes up dramatically.

finding the right vps provider

so what’s the alternative? go old school: a virtual private server (vps). but choosing the right provider matters.

i spent weeks researching vps providers, comparing:

• price
• performance
• reliability
• data center locations
• virtualization technology
• support quality

after all that research, i went with hetzner. why?

1. they’re eu based (important for my potential customers)
2. they offer arm-based servers that are more cost-effective
3. their prices are shockingly good (i’m paying about €3.5/month for my 2vcpu/4gb ram box)
4. their network performance is excellent
5. they don’t nickel-and-dime you on bandwidth

other solid options were linode (now akamai), digitalocean, and vultr - but hetzner won on pure price-to-performance ratio. plus, they don’t try to upsell you on a thousand different managed services.

the constraints i’m working with

let’s be honest about what i have to work with:

• budget: as close to “practically free” as possible until revenue exists
• time: limited because i have a day job (and occasionally need sleep)
• hardware: a single arm-based vps with 2 vcpus, 4gb ram, and 40gb storage
• team: just me and the occasional rubber duck i talk to

these constraints aren’t unusual for solo founders, but they do require a different approach to infrastructure than what you’d do at a funded startup or enterprise.

my architecture in a nutshell

after much deliberation (and several nights of cursing at the cloud), i settled on this approach:

┌───────────────────────────── public network ─────────────────────────────┐
│                                                                          │
│                                   │                                      │
│                                   ▼                                      │
│           ┌───────────────── traefik (reverse proxy) ─────────────────┐  │
│           │                                                           │  │
└───────────┼───────────────────────────────────────────────────────────┼──┘
            │                         │                                 │    
            ▼                         ▼                                 ▼    
┌─────────────────────┐    ┌────────────────────┐    ┌────────────────────┐
│      casahouse      │    │      mojodojo      │    │     monitoring     │
│   (frontend web)    │    │    (backend api)   │    │ (prometheus etc.)  │
└─────────────────────┘    └─────────┬──────────┘    └──────────┬─────────┘
                                     │                           │          
                                     ▼                           │          
                          ┌───────────────────┐                  │          
                          │    postgresql     │                  │          
                          │    (database)     │                  │          
                          └───────────────────┘                  │          
                                                                 ▼          
                                                     ┌───────────────────┐  
                                                     │   node-exporter   │  
                                                     │     cadvisor      │  
                                                     └───────────────────┘  

the key components:

1. docker swarm for orchestration (because kubernetes on a single node is like using a sledgehammer to hang a picture)
2. traefik as the edge router/reverse proxy with automatic ssl
3. microservices architecture for my applications (casahouse frontend, mojodojo api)
4. postgresql for the database (because sql is actually good, despite what the internet tells you)
5. monitoring stack (prometheus, grafana, loki) because flying blind is terrifying

each of these choices was made with my constraints in mind. let me break down why.

docker swarm: the unsung hero for solo founders

everyone and their hipster cousin is using kubernetes these days. and sure, if you have a team of devops engineers and a budget for managed services, go for it.

but as a solo founder? kubernetes is like buying a nuclear power plant to charge your phone.

why swarm over kubernetes

docker swarm gives me:

• container orchestration with way less complexity
• built-in service discovery and load balancing
• rolling updates and health checks
• secrets management
• all in a system that doesn’t require a certification program to understand

and it runs beautifully on a single node. when i eventually need to scale, i can add nodes to my swarm without redesigning everything.

the microservices balancing act

i know what you’re thinking: “microservices for a solo project? are you insane?”

maybe a little bit, but there’s a method to my madness.

finding the right granularity

i’ve split my application into just a few logical services:

• casahouse: the react frontend (purely static)
• mojodojo: the go backend api
• postgresql: for persistence

this gives me just enough separation to manage each component independently, without fragmenting into “microservice hell” where i’d spend all my time managing inter-service communication.

it’s not “true microservices” as described in textbooks, but it’s a pragmatic approach that works for my scale.

debunking the “you need cloud providers” myth

let’s directly address another big misconception: the idea that you need fancy cloud provider services to be “enterprise ready.”

big cloud providers have done an amazing marketing job convincing developers that building reliable systems requires their complex managed services. it’s simply not true.

let’s look at what “enterprise ready” actually means:

1. high availability: can be achieved with proper monitoring and automated recovery procedures, even on a single server to start
2. security: more about good practices than fancy services
3. scalability: most startups don’t need to scale beyond what a few well-configured servers can handle for years
4. reliability: often more dependent on your application architecture than your infrastructure

in my experience at larger companies, the most stable and cost-effective systems were often the simplest ones with the fewest moving parts.

i’m not saying you’ll never need aws or gcp. but you definitely don’t need them to start, and you may not need them for a lot longer than you think.

multi-tier networking for actual security

security is one area where i refuse to compromise, even on a tight budget. my network architecture has three isolated tiers:

• public network: only traefik and public-facing components
• backend network: for service-to-database communication
• monitoring network: for metrics and logging

this way, even if someone somehow breaches my frontend, they don’t automatically get access to my database or monitoring tools.

this kind of network isolation is enterprise-grade security, and it costs me nothing but a little configuration effort.

observability: you can’t fix what you can’t see

one lesson i’ve learned from enterprise environments is that good monitoring is not optional. but traditionally, good monitoring has been expensive in terms of both money and resources.

most cloud providers will try to sell you their monitoring solutions at premium prices. but with open source tools and a bit of configuration, you can build a monitoring system that rivals what the big players offer.

my lightweight monitoring stack

my solution:

• prometheus for metrics collection
• node-exporter and cadvisor for system and container metrics
• loki for log aggregation
• grafana for visualization
• alertmanager for notifications when things break

the entire stack runs with minimal resource usage and gives me visibility comparable to what i had at much larger companies.

resource allocation

resource allocation is critical when you’re running on minimal hardware. here’s how i’ve divided things up:

tight resource limits ensure no single component can take down the entire system if it misbehaves.

deploying like a professional (but alone)

deployment is where many solo projects fall apart, ending up with manual processes that are error-prone and time-consuming.

my gitops-inspired workflow

i’ve implemented a simple gitops-inspired workflow:

1. push code to github
2. github actions build container images
3. images get published to github container registry
4. a simple deploy script pulls new images and updates the swarm

it’s automated enough to be reliable, but simple enough that i understand every step and can fix it when things inevitably break.

backup and recovery: because stuff breaks

nothing kills customer trust faster than losing their data. my approach to backup is simple but effective:

• daily postgresql dumps stored off-server
• configuration backed up in version control
• documented recovery procedures i’ve actually tested

the key is not just having backups, but knowing they work and how to use them. i’ve intentionally “broken” my system several times to practice recovery.

the case for “enterprise-lite” as a solo founder

after looking at all these components together, i realized i’ve developed an approach i call “enterprise-lite” - taking the core principles that make enterprise infrastructure reliable, secure and observable, but implementing them in ways that are maintainable by a single person.

many solo founders make one of two mistakes:

1. using overly simplistic setups that can’t scale or lack security
2. copying enterprise architectures that are too complex to maintain alone

instead, i’m advocating for a middle path that gives you the benefits without the overhead.

what you get with enterprise-lite

with the setup i’ve described, i get:

• reliability comparable to much larger systems
• security that would pass basic compliance requirements
• observability that catches issues before users notice
• scalability that can grow with my business

all while keeping costs around €3.5/month and maintenance overhead minimal enough for one person to handle.

what’s next in this series

this post is just an overview of my approach. in the coming posts in this series, i’ll dive deeper into:

1. setting up docker swarm for production use
2. implementing multi-tier networking
3. security best practices for solo founders
4. building a lightweight but effective monitoring stack
5. continuous deployment without the complexity
6. backup and disaster recovery that actually works
7. performance optimization for resource-constrained environments

if you’re a solo founder building infrastructure, or just interested in how to run production-grade systems on a budget, follow along. i promise to keep it real - sharing both successes and the inevitable disasters.

conclusion

building enterprise-grade infrastructure as a solo founder isn’t about having the fanciest tools or the most complex architecture. it’s about understanding the core principles that make systems reliable, secure, and maintainable - then implementing those principles in ways that fit your constraints.

i hope this overview has shown that you don’t need a team of devops engineers or a massive aws budget to build something solid. you just need to be thoughtful about your choices and pragmatic about your implementation.

the cloud giants have convinced many of us that we need their complex services to build “real” systems. but the truth is, with the right approach, a simple vps and some well-configured open source software can take you surprisingly far.

in the next post in this series, i’ll dive deeper into docker swarm setup and why it’s the perfect orchestration choice for solo founders. i’ll show you exactly how i configured my swarm for production use, including the gotchas i discovered along the way.

feel free to reach out if you have questions or want to share your own solo infrastructure experiences. we’re all figuring this out as we go.