DEV Community: Bogdan

The Self-Hosting Rabbit Hole

Bogdan — Fri, 11 Apr 2025 21:13:22 +0000

Trading convenience for over-optimization is a sin that has killed the momentum of many projects. But if you lower the stakes and package this swap as a learning opportunity, it suddenly becomes excusable, even encouraged.

Until recently, I was a paying customer of a cloud-hosted analytics platform built on an open-source core. Then I turned to Coolify, a PaaS (Platform as a Service) for managing self-hosted codebases, to try running that same open-source version myself. In fact, I was so excited to finally try out Coolify, I was actually looking forward to the DevOps headaches I was inevitably about to run into.

I already had servers up in production, and my Plausible Analytics bill was getting expensive. However, the convenience of the low-hanging fruit or cost-cutting played no major role here. The possibility of introducing a significant improvement to my usual deployment workflow was the real catalyst.

If you're already familiar with platforms like Heroku or Vercel, you know that you're paying for the convenience of running your code on AWS's infrastructure without dealing with AWS's complexity. These platforms "wrap" the power of the Amazon's cloud, and serve it to their customers in a streamlined form. This is more convenient for someone with no DevOps experience, and people are often willing to pay a premium for convenience.

Think of Coolify as a similar abstraction layer - it simplifies the process of managing your own server, removing much of the manual configuration.

Without Coolify:

you need to manually ssh into your server
configure Nginx
use docker compose to orchestrate your database, backend, frontend, etc.
need a to deploy the latest version of your applictaion? you need to ssh again and pull the latest updates from your remote.

With Coolify:

you access your server via a web interface
you link it to your own GitHub account
select the repos Coolify should have access to
every push to the main/ master branch will trigger a new production deployment; no need to ssh into your server and clone the latest version of your repository

Is life without Coolify really that bad? No, not at all. It's like driving a car with manual transmission. If you're a real car buff, you might actually like it better. I know I do.

Additionally, too much abstraction can take the fun away. In the right scenario, abstraction makes processes more efficient. A human will never be able to shift gears as fast as an automatic transmission, and I will need to take just a bit longer to deploy my apps without something like Coolify.

How to start self-hosting

I use servers with dedicated vCPUs from Hetzner. You can get a VPS capable of running production applications, for $20/mo ($15 for the server + $5 for the automatic backups). The costs are capped (better said, fixed), so you won't have any unpleasant surprises when you get the monthly bill.

I initially installed Coolify on an existing VPS that already had a few manually configured containers. This made setting up Coolify more complicated than it had to be. Simply running docker-compose down wasn’t enough to avoid conflicts. Because of this, I highly recommend installing Coolify on a fresh server.

In fact, the most time-consuming problem I faced could have been avoided if I had started with a clean server. After completing the setup, I ran into an issue where Coolify was running properly, but the server itself was inaccessible from localhost.

I only discovered the real cause a few days later when I tried assigning custom subdomains. The issue? Coolify’s built-in proxy (Traefik) was being blocked by Nginx, which was still running from my previous container setup.

The issue in question:

Server is not reachable. Reason: root@host.docker.internal: Permission denied (publickey).

For a step by step guide that walks you through installing Coolify, check out my DevOps repository.

Why add another layer of complexity?

Vendor lock-in is always a risk. When a platform controls both your tooling and your infrastructure, they can raise prices overnight, and there’s not much you can do about it. That’s what happened with Heroku in 2022. Heroku was my go-to place for launching my Django projects. Additionally, Heroku was an important platform for researchers and hobbyists. 6 years ago, every cool Computer Vision project I was seeing on Twitter was hosted on Heroku.

Unfortunatelly, Vercel followed a similar path in 2023. Crazy pricing changes. This was even more concerning. Since Vercel makes Next.js, it’s no surprise that deploying Next.js apps over there is a smooth experience. But what happens when you want to leave?

People talk as if hosting Next.js outside Vercel is some huge ordeal, but in my experience, it’s been surprisingly easy. I kept seeing posts on Twitter/X about how difficult it was, so I expected a mess. Instead, I found that with a bit of configuration, it works just fine on a basic VPS. It’s not quite as plug-and-play as Vercel, but it’s nowhere near the nightmare people make it out to be.

That said, I still have projects hosted on Vercel. I’m not their biggest fan, but I respect the fact that they at least offer a free tier for early-stage projects. If they ever get rid of that though, I imagine we’ll see history repeat itself.

Further down the rabbit hole

I was already comfortable running my own code on my own infrastructure. By hosting Plausible myself, I was joining a growing trend in tech—people running their own instances of open-source software: sometimes to learn, sometimes to save money, sometimes just for the fun of it.

When you build something yourself, you know exactly how it works. If something breaks, you can usually guess why. But running someone else’s code is different. It comes with its own assumptions, constraints, and quirks that you have to figure out as you go.

There was a time when the Coolify team offered Plausible as a 1-click install, but due to a dispute, this option is not longer available. With that said, Plausible is still an easy deployment. But I couldn't resist looking deeper into its inner workings.

One interesting discovery was Plausible's data storage approach: PostgreSQL for transactions and ClickHouse for OLAP. I'd worked with analytical databases in ML pipelines before, where query speed on large datasets matters. Seeing these two types of databases working together in a production system showed me how they complement each other in practice.

Figuring this process out was so much fun, I already have my eye out for other prospective self-hosted candidates.

Final thoughts

Why would anyone pay for Plausible's hosted version when they could just run it themselves?

I believe it is for the same reason people use Heroku or Vercel instead of raw AWS (which is already an abstraction in itself). Sure, you don't technically need them, but AWS is for professionals, it is complex. Regular people value simplicity.

Plausible works the same way. The community edition is free, but running it yourself means handling servers, maintenance, and updates. If you choose their cloud version, you don't have to worry about any of that.

Additionally, they have employed a really smart tactic. To create a protective barrier for their paid version, they only update the open-source release twice a year. This way, they can claim that their Plausible is "cutting edge" and the Community Edition is "stable".

This is a dream scenario for them. Since they've reached a critical mass of users, and an even more impressive fanbase, the open source community builds their product, while they focus on keeping the business viable. Lesson learned. I am actually applying this to one of my own projects.

Self-hosting is a great learning experience. But at the end of the day, the real question is: are you in the right position to trade convenience for optimization?

Bogdan Andrei, April 2025

The Gap That LeetCode's 30 Days of JavaScript Actually Fills

Bogdan — Sat, 14 Dec 2024 23:51:19 +0000

Most coding challenges teach you to solve puzzles. LeetCode's 30 Days of JavaScript study plan does something different: it shows you how puzzle pieces can transform into bricks, ready to build real-world projects.

This distinction matters. When you solve a typical algorithmic problem, you're training your mind to think abstractly. But when you implement a debounced¹ function or build an event emitter², you're learning how real software works.

I discovered this while working through the challenges myself. The experience was less like solving brain teasers and more like archaeology - uncovering specific, modern JavaScript concepts. Each section focused on another piece of JS's modern features.

The peculiar thing about this study plan is that it won't teach you JavaScript. In fact, I believe you need to already know JavaScript reasonably well to benefit from it. What it teaches instead is how JavaScript is actually used to solve real engineering problems.

Consider the Memoize³ challenge. On the surface, it's about caching function results. But what you're really learning is why libraries like React need memoization to handle component rendering efficiently. Or take the Debounce¹ problem - it's not just about implementing delays; it helps you understand, firsthand, why every modern frontend framework, elevator, and basically any system with an interactive UI, need this pattern.

This focus on practical patterns rather than language basics creates an interesting constraint; you need to be in one of two positions to benefit:

You understand CS fundamentals (especially Data Structures and Algorithms) and are comfortable with JavaScript
You're strong in CS theory and have some prior JavaScript exposure

Bridging CS and Software Engineering

Something odd happens between learning computer science and practicing software engineering. The transition feels like learning chess theory for years, only to find yourself playing a different game entirely - one where the rules keep changing and most moves aren't in any book.

In CS, you learn how a binary tree works. In software engineering, you spend hours debugging your API, trying to understand why the response caching isn't working. From a distance, the overlap between these worlds might seem significantly bigger than it actually is. There is a gap there, and it can often shock CS graduates when they start their careers. Unfortunately, most educational resources fail to bridge it. They either stay purely theoretical ("here's how quicksort works") or purely practical ("here's how to deploy a React app").

What makes this JavaScript study plan interesting isn't that it's particularly well-designed - it's that it creates connections between these worlds. Take the memoization problem: 2623. Memoize³. In CS terms, it's about caching computed values. But implementing it forces you to grapple with JavaScript's peculiarities around object references, function contexts, and memory management. Suddenly,
you're not just learning an algorithm - you're starting to understand why something like Redis exists.

This style repeats throughout the challenges. The Event Emitter² implementation isn't just about a textbook observer pattern - you can look at it as the reason why taking the V8 engine out of the browser, and building Node.js around it, actually made sense. The Promise Pool⁴ tackles parallel execution, a.k.a., the reason why your database needs connection limiting.

The Hidden Curriculum

The sequence of problems in this study plan isn't random. It's building a mental model of modern JavaScript, layer by layer.

It starts with closures. Not because closures are the simplest concept - they're notoriously confusing - but because they're foundational to how JavaScript manages state.

function createCounter(init) {
    let count = init;
    return function() {
        return count++;
    }
}

const counter1 = createCounter(10);
console.log(counter1()); // 10
console.log(counter1()); // 11
console.log(counter1()); // 12

// const counter1 = createCounter(10);
// when this^ line executes:
// - createCounter(10) creates a new execution context
// - local variable count is initialized to 10
// - a new function is created and returned
// - this returned function maintains access 
// to the count variable in its outer scope
// - this entire bundle 
// (function (the inner one) + its access to count) 
// is what we call a closure

This pattern is the seed of all state management in JavaScript. Once you understand how this counter works, you understand how React's useState works under the hood. You grasp why module patterns emerged in pre-ES6 JavaScript.

Then the plan moves to function transformations. These teach you function decoration - where functions wrap other functions to modify their behavior. This isn't just a technical trick; it's how Express middlewares work, how React higher-order components operate,
and also how TypeScript decorators work.

By the time you reach the asynchronous challenges, you're not just learning about Promises - you're discovering why JavaScript needed them in the first place. The Promise Pool⁴ problem isn't teaching you an innovative, quirky JS concept; it's showing you why connection pooling exists in every database engine.

Here's a rough mapping of the study plan's sections to real-world software engineering concepts:

Closures → State Management
Basic Array Transformations → Basic skill (auxiliary); Practical Example: Data Manipulation
Function Transformations → Middleware Patterns
Promises and Time -> Async Control Flow
JSON -> Basic skill (auxiliary); Practical Example: Data Serialization, API Communication
Classes (especially in the context of Event Emitters) → Message Passing Systems
Bonus (Premium Locked) -> Mix of harder challenges that could've been included in the sections mentioned above; Promise Pool⁴ is my favourite one from this section

Pattern Recognition, Not Problem Solving

Let's dissect some problems that showcase this study plan's real value.

Memoize (#2623)

Consider the Memoize challenge. What I love about it, is the fact that the best solution (that I was able to come up with)
is so straightforward, it's as if the code itself is gently telling you what it does (still, I included some comments).

This doesn't make #2623 an easy problem, by any means. I needed 2 previous iterations to make it this clean:

/**
 * @param {Function} fn
 * @return {Function}
 */
function memoize(fn) {
    // Create a Map to store our results
    const cache = new Map();

    return function(...args) {
        // Create a key from the arguments
        const key = JSON.stringify(args);

        // If we've seen these arguments before, return cached result
        if (cache.has(key)) {
            return cache.get(key);
        }

        // Otherwise, calculate result and store it
        const result = fn.apply(this, args);
        cache.set(key, result);
        return result;
    }
}

const memoizedFn = memoize((a, b) => {
    console.log("computing...");
    return a + b;
});

console.log(memoizedFn(2, 3)); // logs "computing..." and returns 5
console.log(memoizedFn(2, 3)); // just returns 5, no calculation
console.log(memoizedFn(3, 4)); // logs "computing..." and returns 7


// Explanantion:
// It's as if our code had access to an external database

// Cache creation
// const cache = new Map();
// - this^ uses a closure to maintain the cache between function calls
// - Map is perfect for key-value storage

// Key creation
// const key = JSON.stringify(args);
// - this^ converts arguments array into a string
// - [1,2] becomes "[1,2]"
// - we are now able to use the arguments as a Map key

// Cache check
// if (cache.has(key)) {
//     return cache.get(key);
// }
// - if we've seen these arguments before, return cached result;
// no need to recalculate

Debounce (#2627)

Imagine you're in an elevator, and there's a person frantically pressing the "close door" button repeatedly.

press press press press press

Without debouncing: The elevator would try to close the door at every single press, making the door mechanism work inefficiently and possibly break.

With debouncing: The elevator waits until the person has stopped pressing for a certain time (let's say 0.5 seconds) before actually trying to close the door. This is much more efficient.

Here's another scenario:

Imagine you're implementing a search feature that fetches results as a user types:

Without debouncing:

// typing "javascript"
'j' -> API call
'ja' -> API call
'jav' -> API call
'java' -> API call
'javas' -> API call
'javasc' -> API call
'javascr' -> API call
'javascri' -> API call
'javascrip' -> API call
'javascript' -> API call

This would make 10 API calls. Most of them useless since the user is still typing.

With debouncing (300ms delay):

// typing "javascript"
'j'
'ja'
'jav'
'java'
'javas'
'javasc'
'javascr'
'javascri'
'javascrip'
'javascript' -> API call (only one call, 300ms after user stops typing)

Debouncing is like telling your code: "Wait until the user has stopped doing something for X milliseconds before actually running this function."

Here's the solution to LeetCode #2627:

/**
 * @param {Function} fn
 * @param {number} t milliseconds
 * @return {Function}
 */
var debounce = function (fn, t) {
  let timeoutID = null;
  return function (...args) {
    clearTimeout(timeoutID); // MDN reference: https://developer.mozilla.org/en-US/docs/Web/API/Window/clearTimeout
    timeoutID = setTimeout(() => {
      fn.apply(this, args);
    }, t);
  };
};

// tests
const log = debounce(console.log, 100);

console.log("Starting tests...");

setTimeout(() => log("Test 1"), 50); // should be cancelled
setTimeout(() => log("Test 2"), 75); // should be cancelled
setTimeout(() => log("Test 3"), 200); // should be logged at t=300ms

setTimeout(() => {
  console.log("Tests completed.");
}, 400);

// Explanantion:
// - we create a closure where timeoutID persists between calls
// - timeoutID starts out as null
// - we return the debounced version of the initial function

// const log = debounce(console.log, 100);
// - this^ creates a new closure with its own timeoutID
// - log is now the inner function

// setTimeout(() => log("Test 1"), 50);  // at t=50ms
// setTimeout(() => log("Test 2"), 75);  // at t=75ms
// setTimeout(() => log("Test 3"), 200); // at t=200ms

// t=50ms: 
// - log("Test 1") called
// - clears timeoutId (null, so nothing happens)
// - sets new timeout to run at t=150ms

// t=75ms: 
// - log("Test 2") called
// - clears previous timeout (cancels "Test 1")
// - sets new timeout to run at t=175ms

// t=200ms:
// - log("Test 3") called
// - clears previous timeout (cancels "Test 2")
// - sets new timeout to run at t=300ms

// t=300ms:
// - finally executes fn("Test 3")


// why this works:
// - the closure keeps timeoutId alive between calls
// - every new call cancels the previous timeout
// - only the last scheduled timeout actually runs

Other common real-world use cases for debouncing (apart from search bars):

Save drafts (wait until user stops editing)
Submit button (prevent double submissions)

What It Gets Wrong

I hope that, from the overall positive tone of this article, my opinion on 30 Days of JS has become clear by now.

But no educational resource is perfect, and, when it comes to limitations, honesty is valuable. This study plan has several blind spots worth examining.

First, the study plan assumes a certain level of prior knowledge.
If you're not already comfortable with JavaScript, some of the challenges can be overwhelming. This can be discouraging for beginners who might have had other expectations from the study plan.

Second of all, the challenges are presented in an isolated manner.
This makes sense in the beginning, but can be a disappointing thing to realize as you progress through the plan. Real-world problems often require combining multiple patterns and techniques. The study plan could benefit from more integrated challenges that require using several concepts together (exception: we do use closures all throughout the plan). These could fit well in the Bonus section (which is already reserved to premium users).

At last, the main weakness of this set of challenges lies in its concept explanations. Coming from competitive programming,
I'm used to clear definitions of new terms and concepts in problem statements. However, LeetCode's descriptions are often unnecessarily complex - understanding their explanation of a debounced function is harder than implementing the actual solution.

Despite its shortcomings, the study plan is a valuable resource for understanding modern JavaScript.

Beyond the 30 Days

Understanding these patterns is just the beginning.
The real challenge is recognizing when and how to apply them in production code. Here's what I've discovered after encountering these patterns in the wild.

First, these patterns rarely appear in isolation. Real codebases combine them in ways the challenges can't explore. Consider a search feature, implemented from scratch. You might find yourself using:

Debounce for input handling
Memoization for result caching
Promise timeouts for API calls
Event emitters for search state management

All these patterns interact, creating complexity that no single challenge prepares you for. But, having implemented each piece yourself, you get a general idea of how the whole implementation is supposed to function.

Counterintuitively, the most valuable skill you will gain isn't implementing these patterns - it is recognizing them in other people's code.

Final Thoughts

After completing this study plan, coding interviews aren't the only place where you'll recognize these patterns.

You'll spot them in open source code, in your colleagues' pull requests, and might start noticing them in your past projects. You might had implemented them before, without even realizing it. Most importantly, you'll understand why they're there.

What started as puzzle-solving transformed into a deeper understanding of modern JavaScript's ecosystem.

That's the gap this study plan fills: bridging theoretical knowledge with practical engineering wisdom.

2627. Debounce (Promises and Time) ↩
2694. Event Emitter (Classes) ↩
2623. Memoize (Function Transformations) ↩
2636. Promise Pool (Bonus) ↩