Forem: Eric Tron

I run 3 side projects (and a TeamSpeak) on a single €10/month server

Eric Tron — Mon, 02 Mar 2026 13:08:27 +0000

I'm not spending €50/month on hosting for projects that might never take off. So I put all three on a single €10/month server.
There's also a TeamSpeak server running on it. With Discord now asking for face scans and leaking government IDs, some of us are going back to basics.

What's running on it

MyOwly : a free app that sends you reminders for your subscriptions, free trials, and anything with a due date. Never miss a renewal again.
React, Spring Boot, PostgreSQL

EsportHub.io : an esports platform available as a web app and an Android app.
React, Spring Boot, MongoDB

ProductCompanies : a search engine for European companies that build cool products.
React, Node.js, MongoDB

The server

It's the cheapest dedicated server on OVH's Kimsufi platform. €10/month, and here's what you get:

CPU: Intel Xeon E5-1620v2 — 4 cores / 8 threads @ 3.7 GHz
RAM: 32 GB ECC
Storage: 1 × 120 GB SSD
Bandwidth: 500 Mbit/s

It's not a fancy cloud instance. It's a real dedicated machine sitting in a datacenter, and it's more than enough.

How it all fits together

The setup is dead simple. One nginx instance handles everything, it receives all the traffic and routes it to the right app based on the domain name.

Each backend runs on its own port:

  Internet
     │
     ▼
    nginx (:443)
     ├── myowly.com        → React static + Spring Boot (:8086) + PostgreSQL
     ├── esporthub.io       → React static + Spring Boot (:8080) + MongoDB
     └── productcompanies.eu → React static + Node.js (:3001) + MongoDB

The frontends? Just static files. React builds into a bunch of HTML, CSS, and JS that nginx serves directly. No Node server needed for that.

SSL is handled by Let's Encrypt, free HTTPS on all domains, auto-renewed.

And each backend is managed by systemd. If something crashes (it hasn't in 78 days, but still), it restarts automatically. No Docker, no Kubernetes, no orchestration. Just good old Linux doing its
thing.

The real numbers

With all three projects running, the server barely notices. CPU usage sits at 1%. I'm using 3 GB of RAM out of 32, that's 28 GB doing absolutely nothing. Disk? 14 GB out of 120.

Each Spring Boot app takes around 500 MB of RAM, the Node.js one takes 110 MB, and the databases combined use about 300 MB. I could realistically throw 15 more apps on this thing before it starts to
sweat.

Why not the cloud?

Every time I look at cloud platforms, I see the same thing: one service for the backend, another for the frontend, a managed database on the side, then you spend an hour wiring everything together. And
at the end of the month, you're paying €20-50 per project for something that has three users.

I'm building a product, not scaling for 100,000 users. These are side projects. They might take off, they might not. I'd rather spend my time shipping features than configuring cloud dashboards.

And if one of them actually blows up? I'll move it to its own dedicated server on Kimsufi, OVH, or Scaleway, European providers first, set up Docker and Kubernetes, and scale horizontally. But until that day comes, a single €10/month box does the job just fine.

There's another benefit I didn't expect: you actually learn how things work. Setting up nginx, configuring SSL, writing systemd services, debugging logs over SSH, none of that happens when you click
"Deploy" on Vercel. Managing your own server makes you a better developer, and that knowledge doesn't go away when a platform changes its pricing.

Wrapping Up

Three full-stack apps, two databases, a TeamSpeak container running in Docker, and the server is still 97% idle. All of that for €10/month.

You don't need Kubernetes. You don't need a managed database at €30/month. You don't need five different cloud services to run a side project. I use a dedicated server, but even a €5/month VPS would handle most side projects better than a patchwork of cloud services.

Start cheap, ship fast, scale when you need to.

Thanks for reading. If you have questions about the setup or want to roast my architecture, the comments are open.

Why I Chose a Monolithic Architecture for My Side Project

Eric Tron — Mon, 03 Mar 2025 14:20:21 +0000

Beyond Outsized Ambitions

When I started working on MockFast, I had no intention of creating the next Silicon Valley unicorn. It was just me being fed up with reinventing the wheel for every new project. Something I was tinkering with in the evenings after work, or for a few hours on weekends when my girlfriend would leave me alone for a bit.

My journey creating mockfast.io - a free API mocking tool

Eric Tron ・ Feb 28

#webdev #programming #api #productivity

Between a job that already takes 40-50 hours per week, the usual chores, and wanting to actually have some kind of social life, you gotta be realistic about what you can accomplish. I had maybe 5-10 hours a week to dedicate to this personal project. Under these conditions, you really need to focus on the essentials.

After some times of development (with plenty of breaks, let's be honest), the main lesson I learned: the difference between a finished project and an abandoned one is often just staying pragmatic. Nobody has ever used a perfectly designed project that was never completed.

Seriously, we all start with big dreams, but we need to come back down to earth. If you have 100 users after a year, that's already an incredible success for a side project. So why bother with an architecture that could handle 100,000 users if it means you'll never actually finish?

Don't get me wrong - microservices are awesome even if you don't have tons of users. They're fantastic if your primary goal is learning the ins and outs of modern distributed architectures. I've got colleagues who've built incredibly complex systems just to learn how Kubernetes orchestration works or to master event-driven architecture patterns. Thats a perfectly valid reason to go that route. But for me, this project wasn't primarily about learning new tech - it was about solving a real problem and actually shipping something useful.

Simplicity as a Deliberate Strategy

My goals were pretty straightforward:

Solve a real problem that was frustrating me daily
Learn some interesting things and actually enjoy the building process
Create something useful without burning myself out
Avoid unecessary complexity that would just slow me down

A monolithic architecture let me:

Build quickly without drowning in infrastructure setup
Focus on solving the actual problem instead of architecting endlessly
Reduce the mental overhead of tracking too many components
Keep the project enjoyable and doable (because who needs more stress?)
Iterate faster and see actual results rather than just planning

Simplicity wasn't a comprimise – it was my strategy for making measurable progress with the limited time and energy I had.

The Hidden Burden of Premature Optimization

Microservices sound impressive in tech talks, but for a side project, they're often just adding complexity that you don't need. Breaking down an application into microservices requires:

Significant time upfront just designing everything
Setting up complex infastructure that will cause headaches at midnight
Mental energy that could be used for more important aspects
Time taken away from building features users might actually care about

I've seen several promising side projects (including some of my own) get stuck in a swamp of permature optimizations, only to be abandoned before they ever reached users. Even the most elegant architecture is useless if your project never sees the light of day.

When you're coding in those limited evening hours after work, every hour is precious. I'd rather spend my energy building something that solves problems than configuring systems that nobody asked for.

Resources Are Limited (Especially Time)

Let's be realistic: side projects happen in those small slices of time you find between other committments. Every hour spent:

Dealing with complex architectures and getting lost in configuration files
Trying to make distributed systems work together properly
Troubleshooting communication issues between services
Researching solutions to problems that only exist because of your architecture choice

is an hour not spent:

Building features that make your project actually useful
Solving interesting technical challenges that matter to your project
Using and enjoying your own creation (which is a big part of motivation)
Getting feedback to see if you're even on the right track

Time is the scarcest resource in a side project – and never seems to be enough of it. I've never once found myself with too much free time for my side projects, and I doubt you have either.

User Experience Trumps Technical Excellence

An interesting thing I discovered while building MockFast – not a single user has ever asked me about my architecture decisions. No one really cares if I'm using microservices, a monolith, or any other technical approach. What actually matters to them:

Does the service work reliably when they need it?
How quickly can issues be fixed when something goes wrong?
Can they figure out how to use it without extensive documentation?
Does it actually improve their workflow in some meaningful way?

A reliable monolith that works consistantly is far more valuable than a perfectly designed distributed system that's perpetually "almost ready" or breaks in unpredictable ways.

When Will Microservices Make Sense?

I'm not saying microservices are wrong or that I'll never consider them. The transition isn't off the table – it's just postponed until it actually becomes necessary. I'll consider breaking things up when:

The project has actual users who depend on it
Certain components need to scale independently because of usage patterns
Performance becomes a genuine problem rather than a theoritical concern
I have more consistent time to invest in development
The benefits clearly outweigh the additional complexity of managing multiple services

The key is being honest about whether your addressing real problems or just following tech trends. Most side projects are built for dozens or hundreds of users, not millions, and our architecture choices should reflect that reality.

The Progressive Migration Strategy

My approach isn't completely without planning though. My current strategy involves:

Writing modular code where possible (without sacrificing progress)
Following clean architecture principals where it makes sense
Keeping components loosly coupled to avoid creating a maintainance nightmare
Keeping potential future decomposition in mind as I develop
Noticing which parts of the system naturally want to be seperate

Nothing fancy or over-engineered, but it keeps development moving forward without creating to many technical constraints for the future.

It's Not Technical Debt – It's Strategic Simplicity

This isn't about being lazy or taking shortcuts. It's about being realistic and making pragmatic choices that maintain momentum.

Real technical debt isn't choosing a monolithic approach – it's writing poorly structured code, avoiding tests for critical functions, or having insufficient documentation. A well-designed monolith can be much easier to maintain than a collection of microservices that were implemented hastily because they seemed more sophisticated.

Lessons from the Trenches: What I've Learned Along the Way

After working on MockFast for about a year (with plenty of breaks and distractions), I've learned some valuable lessons:

Unexpected Evolution: The features users value most weren't the ones on my initial roadmap.
Quick Feedback Loops Matter: Being able to implement changes quickly meant I could respond to user feedback rapidly, which made a huge difference.
Motivation Needs Reinforcement: It's much easier to stay motivated when you're shipping actual features rather than spending weeks on invisible infrastructure work.
Finding Balance is Hard: Navigating the space between "good enough" and "perfect" is a constant challenge, but leaning toward "functional now" has generally been the right choice.

Conclusion: Enjoy the Journey

When it comes to side projects, the best architecture isn't necessarily the most sophisticated or trendy - it's the one that enables you to:

Build something meaningful without overwhelming yourself
Learn valuable new skills along the way
Solve actual problems that bother you or others
Find enjoyment in the process rather than creating another source of stress

For MockFast, that means maintaining simplicity, staying adaptable, and avoiding the trap of over-engineering that has killed so many promising side projects.

Key Takeaways:

Side projects succeed when you keep them managably simple
Monoliths are often the smart strategic choice for individual developers
Your architecture should support your project goals, not impress other developers
If the project stops being enjoyable, re-evaluate your approach
The best architecture is whatever helps you complete your project and get it to users

Remember: The goal is to build something useful that actually makes it to production, not to create the most technically impressive system that forever remains a work in progress.

My journey creating mockfast.io - a free API mocking tool

Eric Tron — Fri, 28 Feb 2025 14:32:51 +0000

I was working on some solo projects last year, and I kept getting so frustrated. Why? Because I always had to create fake API responses for testing my frontend before the backend was ready. Copy-pasting JSON everywhere, maintaining local files, constantly updating them...

Seriously, I was spending more time managing fake data than actually coding!

My "aha" moment

One day, after my test data got completely out of sync with what I was building, I thought "OK, that's enough". I knew there were some tools to create fake APIs, but nothing was exactly what I needed:

json-server? Good but local only
Postman mock? Cool but limited in free version
Hardcode data? Please no
Big paid services? Too expensive for small projects

So I started building my own solution on nights and weekends. I wanted to create something that would help other developers like me. That's how mockfast.io was born - a 100% free cloud service to create API mocks with realistic data.

How it works (simple version)

You just need to:

1) Define what data you want:

{
  "name": "string.name.fullname", 
  "email": "email",
  "age": "number",
  "isActive": "boolean" 
}

2) Choose HTTP method (GET, POST, PUT, DELETE)

3) Configure some options if you want (delay, errors, etc)

And boom! You get a real URL that returns your fake data, like:

https://mockfast.io/backend/apitemplate/get/abc123

When you call it, you get nice random data that matches your template:

{
  "name": "Marie Johnson",
  "email": "marie.j88@example.com",
  "age": 32,
  "isActive": true
}

The fake data library i'm building

One thing I'm really proud of is my custom library for generating fake data. I'm actually building my own version of faker.js but with some tweaks I personally needed.

Right now there are more than 50 data types, like:

Full names, first names, last names
Emails (general or specific like gmail, proton, etc)
Addresses with streets, cities, postcodes
Colors in different formats (hex, rgb, hsl)
Country data with names, capitals, currencies
And more!

If you have ideas for data types you need, tell me! I'm adding new ones all the time based on what people ask for. Last week someone asked for more specific product data, so that's on my list now.

How I use it everyday

Now this tool has become essential for my workflow:

When building new frontend features

I create a mock API with the structure I plan to implement on the backend later
For trying out new UI ideas

No more setting up a whole backend just to test if a UI concept works!
When testing edge cases

Need to test with a super long text? Or with missing data? Or with an API timeout? Just configure the mock how you want.
For quick prototypes

When I have a new idea, I can create a working prototype in hours instead of days

I've shared it with some developer friends and they're using it too. It's really satisfying to see something I built to solve my own problem help other devs!

Some technical details (for the curious)

The service is built with Node.js and has a React frontend. The data generation happens on the server, and everything is cached for speed. I've designed it to be as simple as possible - I hate overcomplicated tools.

I'm currently working on adding:

More data types (especially for specific industries)
Conditional responses
Mock GraphQL APIs (this is tricky but coming soon)
Response templates (save your favorite configurations)

Why it's 100% free?

People ask me this a lot. Honestly, I built mockfast.io to solve my own problems first, but I also wanted to give something back to the dev community. I've benefited from so many free tools and open source projects, this is my way of contributing.

My costs for running it are reasonable for now, and I'd rather see it help as many developers as possible than make a few bucks. It makes me happy when I get messages from people saying it saved them time or made their work easier.

Maybe someday I'll add a "pro" version with advanced features if the hosting costs become too much, but the core functionality will stay free.

Try it & give feedback!

If you're constantly blocked waiting for APIs like I was, give mockfast.io a try. It takes about 30 seconds to create your first mock API.

I'd love to hear what you think. What works? What doesn't? What's missing? I'm just one developer trying to make a useful tool, and your feedback really helps me improve it.

And hey, if you find a bug, please let me know! I fix them fast :)