DEV Community: Raghav

The Art of Vibe Coding With Actual Discipline

Raghav — Mon, 08 Dec 2025 06:14:49 +0000

Why speed feels great but structure keeps you sane

Every day I see developers firing off prompts to tools like Cursor, Claude Code, and every other AI Powered editor out there. The speed is addictive. You get instant wins, quick fixes, and a sense that you’re moving faster than ever. But what this really means is you’re building on shaky ground. It works today, then bites you later.

I want to break down how I use AI in my workflow while building Nixopus, how I wish my teammates approached it, and why keeping core engineering practices intact still matters. Before we get into the solutions, it helps to understand where things start going wrong.

Where vibe coding quietly derails (so as you!)

Vibe coding can make you feel like a 10x engineer, even when you’re not actually steering the ship.
After enough prompts, you lose track of what changed and why. Suddenly you need someone else to explain your own code.
Edits become scattered, inconsistent, and sometimes downright chaotic. I’ve seen people commit things like SUMMARY.md right into their main codebase.
Collaboration becomes a mess because no one shares the same mental model of the project anymore.
Pair programming takes a hit since everyone is locked into their own AI driven bubble.
Knowledge transfer becomes painful. New teammates end up re prompting the model just to understand what’s going on.
The team’s engineering culture starts drifting away from solid, intentional practices.
Running multiple agentic workflows across different repos introduces confusion instead of clarity.
And at the end of the day, you’re reduced to someone who just gives orders to an AI and hopes it does the right thing.

Now that you can probably relate to at least a few of the pain points above, this is where things get interesting. Let’s look at how we can take all that chaos, turn it around, and make vibe coding actually work without sacrificing engineering discipline.

Turning raw prompts into intentional, consistent workflows

Prompting isn’t just a skill anymore. It’s becoming a core part of how we write software with LLMs. The better your prompts, the better your outcomes. And when you treat prompting like an engineering practice rather than a shortcut, you start seeing consistent, predictable results.

Here’s how to approach it.

Ask for step by step output : Break your instructions into clear, sequential steps. It gives the model structure and reduces randomness.
Tell the model when to stop : If you want to review something, specify that the model should pause once a certain part is done. It keeps you in control of the flow.
Interrupt when things drift : If the model starts hallucinating or going off track, stop it immediately and re prompt with a tighter instruction.
Reinforce project rules every time : Mention coding conventions, folder structure, architectural rules, or any non negotiables in your prompt so the model prioritizes them.
Keep a reusable prompt structure : Build templates for feature development, bug fixes, refactoring, testing, and documentation. If you’re using Cursor, keep them inside your .cursor folder for quick access. The same structure can be shared with your team so everyone works with the same clarity.

Review like an engineer, not an AI operator

Writing code with an LLM doesn't end when the editor stops typing. The real work begins at review. Own what you push, catch problems early, and use models as tools not replacements.

Take responsibility You asked the model to write this. When a pull request fills up with comments, don't panic. Lead the review, reply to feedback, and fix issues before they hit main. Ownership keeps the team confident and the codebase healthy.
Self review first Don’t blindly trust the model. Run the code, step through logic, and search for bugs. Remove stray emojis, clean up variable names, and format things the way you would if you wrote it yourself. You are the engineer, the model is the assistant.
Agentic review as a second pass Use an automated reviewer or another model to scan for style, edge cases, or security issues. This is not a replacement for human judgment, treat it as a high quality linter that finds what you might miss.
Fix small issues immediately Address minor comments and nits as they appear. Small problems compound quickly. Fixing them now prevents larger rework later and keeps the review cycle fast.
Think big while shipping small Ship simple, useful changes. But keep an eye on scale. Ask: will this pattern hold at 10x users, or 10x contributors? Balance pragmatic simplicity with design that scales.

Let automation enforce what your team can’t afford to forget

Your CI CD pipeline is the backbone of everything you ship. It starts as early as your pre-commit and pre-push hooks, and it follows your code all the way to production. A strong pipeline enforces discipline even when vibe coding tries to pull you in every direction.

Make sure your pipeline covers the essentials:

Coding standards
Linters and formatters
Compilation and type checks
Commit message rules
Mandatory reviews with enough depth
Extra review cycles when the change is risky

A solid pipeline catches what you miss, keeps your team aligned, and makes sure every feature lands clean.

Care about the process, not just the output

Open source works because people care. They care about the community, the standards, the craft, and the long term health of the project. Small teams that vibe code without shared principles slowly drift into sloppy engineering because the only thing they focus on is the outcome, not how they got there.

If you’re someone who believes process matters, who values clean change history, who refuses to push a feature wrapped in a hundred hidden bugs, then this mindset becomes non negotiable. Respect the craft. Respect the principles. And don’t forget the tactics that keep your workflow sharp.

What you ship is important. How you ship it matters even more.

Follow these steps and vibe coding stops being chaotic. It becomes a fast, accountable way to build without sacrificing engineering craft. These approaches are my way of balancing the things, if you are someone with whom it resonates then feel free to follow me for more such resonating effects!

How Jekyll almost killed our vitepress docs

Raghav — Sun, 13 Jul 2025 15:41:45 +0000

We created Nixopus to simplify self-hosting. Think of it as Heroku or Netlify, but built for developers who want full control, especially when working with Docker apps. Naturally, we used Nixopus itself to host our own documentation in the early days. But as we rolled out alpha builds and moved fast, the setup started pushing back. To make sure our docs stayed accessible and reliable for users, we temporarily shifted to GitHub Pages. That’s when Jekyll, GitHub’s default static site generator, started messing with our VitePress setup. Here’s what happened.

Moving Docs to GitHub Pages: What We Did

We started by setting up a custom domain for our docs at docs.nixopus.com. After adding a CNAME file to the repository, we updated the DNS records to point to GitHub’s servers. Domain validation went through without any hiccups. Next, we had to choose how GitHub Pages would serve our documentation.

We picked the branch method for simplicity. We set it to deploy from the master branch and pointed it to the /docs directory, where our VitePress site lives. That got the docs live on the domain, but it also opened the door to a new set of issues.

The Migration Catastrophe: Looks Like Docs, Feels Like Chaos

When we first got the docs live, something felt off. They loaded, but with zero CSS. No layout, no colors, just raw text sitting on the screen. Technically the site was working, but let’s be honest, it was unusable.

We had a GitHub Action set up to build and deploy the docs on every push to master. At one point, we switched the deployment method from branch based to GitHub Actions, then back again, hoping it would help.

The Actions ran without errors. The pages deployed. But the styling came and went like a ghost. And that kind of inconsistency is the worst kind of bug to chase.

Why We Couldn't Pin Down the Root Cause

We were convinced the problem was with VitePress. This GitHub issue matched what we were seeing almost perfectly, so we tweaked our VitePress config, redeployed, and boom it worked.
For a moment, at least. The next time we pushed to master, the problem came back. No styles again. At this point, our GitHub Actions were running flawlessly. No errors, no skipped steps, nothing unusual.

We opened a Discord thread to track the issue in real time and started logging when the bug would appear. But without a clear pattern, it felt like chasing shadows.

The Burnout Moment

One day, while talking to a Nixopus contributor about the docs issue, something clicked. I opened up the GitHub Actions tab to double check the workflow we were using to build and deploy the documentation. That’s when I noticed something strange two GitHub Actions were running for the same trigger.

I paused. We only had one workflow file in the repo. So where was the second action coming from? I took a closer look at both. One was clearly ours. The other seemed to be generated by GitHub itself, tied to the "Pages" deployment configuration. Suddenly, it made sense. We had unknowingly set

We weren’t going crazy. We were just getting Jekylled.

This one was so ridiculous & funny at the same time, we couldn’t help but laugh once we figured it out. Remember how we chose to deploy from a GitHub branch? Turns out, GitHub was quietly running its own internal deployment step for Pages. At the same time, our custom GitHub Action was also building and deploying the site.

The catch was when GitHub’s default Pages deploy ran first, it served our VitePress site without any CSS. Completely styleless. Then, when our GitHub Action ran after it, it deployed the styled version. That’s why it sometimes looked fine and we were racing against GitHub’s own deploy job. and yep, GitHub’s deploy was using Jekyll under the hood, even though we had no .nojekyll file in the repo. Classic Pages behavior.

Conclusion

What looked like a flaky VitePress bug turned out to be a silent tug-of-war between GitHub Pages and our own deployment pipeline. GitHub was defaulting to Jekyll, quietly breaking our styles, and we didn’t even notice it at first because our own action would sometimes fix it afterward.

The fix? We disabled the default GitHub Pages deploy and let our GitHub Action handle everything. Clean, predictable, and no more surprise Jekyll attacks. Lesson learned ? when something works "sometimes," dig deeper. There's probably a rogue process you didn’t invite to the party.

If you're someone who wants to streamline ServerOps without the usual mess, Nixopus might be exactly what you're looking for. And if you enjoy chasing down weird bugs like this one, join us on Discord we’d love to have you around. Let’s hunt bugs, ship clean infra, and laugh through the chaos together.

From Migrations to Seed : Working with Fixtures in Nixopus

Raghav — Sun, 29 Jun 2025 18:41:52 +0000

Hey, we’re always up for exploring something cool at Nixopus, and this time, we’re diving into fixtures. Now, the word fixtures might sound a bit too technical and not immediately clear to many of our fellow developers so let’s break it down, and you’ll see exactly what we mean. Let’s dive in.

The Breakdown

If you’ve worked with migrations before, you’ve probably come across the term data seeding for databases. Even if you haven’t, let’s take a moment to understand what seeding data actually involves.

By the way, if you’re not familiar with migrations yet, you might want to check out this article to see how we handle them: Inside Nixopus: How We Manage Our Database Migrations.

Usually, during development, things can get tricky over time, especially when you have contributors and developers working together on the same project. Everyone wants everything to be quick and hassle-free so development doesn’t slow down. As a project maintainer, it’s your responsibility to enable this smooth contribution roadmap for any user who wants to help out. That’s exactly what we’re working towards at Nixopus.

One major part of Contributing to Nixopus is that after getting everything set up, Contributor still needs to do the following tasks :

You realize you need an admin user to log in and test admin features.
You also want to create a member user for that organization to test the role based access.
You might even want to enable specific features inside nixopus, and disable some!

This is time consuming and error-prone, especially when you or your teammates need to do it over and over again on fresh databases. That’s exactly where data seeding comes into the picture.

What is Data Seeding?

The process of populating a database with an initial set of data. Simple, isn’t it?

But how do we actually create one in Go using Bun ORM? This is what pushes us to explore how we can write a script to do exactly that.

How Do Seed Files Look?

We’ve divided our seed files into a modular folder structure. This way, everything stays organized and it’s much easier to load schema specific data when you need it.

Below is an example of the file structure and the kind of data we’ll be loading into the database later in our Codebase:

- model: Role

  rows:
    - _id: admin
      id: "{{ uuid }}"
      name: "admin"
      description: "Administrator with full access"
      created_at: "{{ now }}"
      updated_at: "{{ now }}"

    - _id: member
      id: "{{ uuid }}"
      name: "member"
      description: "Regular organization member"
      created_at: "{{ now }}"
      updated_at: "{{ now }}"

    - _id: viewer
      id: "{{ uuid }}"
      name: "viewer"
      description: "Read-only access to resources"
      created_at: "{{ now }}"
      updated_at: "{{ now }}"

The Bun ORM in Action

First things first, we need to get input from the user. Let’s assume the user runs a command like:

go run internal/cmd/fixtures/main.go

Then we want to accept some arguments along with this command to determine what exactly the user is trying to do, we will get into what each flag does later, for now let's go forward

var (
    fixturePath = flag.String("fixture", "fixtures/development/complete.yml", "Path to fixture file")
    recreate    = flag.Bool("recreate", false, "Recreate tables before loading fixtures")
    truncate    = flag.Bool("truncate", false, "Truncate tables before loading fixtures")
)

flag.Parse()

Now that we know what the user is actually trying to do, let’s create a Bun DSN URL which stands for Data Source Name URL, which is a connection string used to configure and connect to databases or services.

Here’s a raw example of what a Postgres DSN URL looks like: postgres://username:password@localhost:5432/database_name?sslmode=disable

Since we don’t want to hardcode credentials, we need to load our secrets like passwords and other configs from environment variables. Here’s how we can do that in Go:

err := godotenv.Load()
if err != nil {
    log.Fatal("Error loading .env file")
}

host     := os.Getenv("HOST_NAME")
port     := os.Getenv("DB_PORT")
username := os.Getenv("USERNAME")
password := os.Getenv("PASSWORD")
dbName   := os.Getenv("DB_NAME")
sslMode  := os.Getenv("SSL_MODE")

if sslMode == "" {
    sslMode = "disable"
}

dsn := fmt.Sprintf(
    "postgres://%s:%s@%s:%s/%s?sslmode=%s",
    username, password, host, port, dbName, sslMode,
)

Once we have our DSN ready, we can check if our connection string is properly formatted and can be parsed without errors. The function we use for this is pgx.ParseConfig:

config, err := pgx.ParseConfig(dsn)
if err != nil {
    log.Fatalf("Failed to parse database config: %v", err)
}

Now that we are ready to go, let's connect to our database and close the connection to database as our program ends

sqldb := stdlib.OpenDB(*config)
defer sqldb.Close()
db := bun.NewDB(sqldb, pgdialect.New())

Now we need to load all our fixtures from the YAML files in our fixtures folder. Here’s a simple flowchart that shows how the loading process works, Read The Code

After we have everything set up, we decide how we want to load the fixtures onto our database. This block of code checks which option the user passed when they ran the command and performs the action accordingly:

if *recreate {
    err = fixtureLoader.LoadFixturesWithRecreate(ctx, *fixturePath)
} else if *truncate {
    err = fixtureLoader.LoadFixturesWithTruncate(ctx, *fixturePath)
} else {
    err = fixtureLoader.LoadFixtures(ctx, *fixturePath)
}

Explanation of the Flags We Considered Earlier

I know you must be waiting for the final touch, it's a lot of code to digest, right? So let’s take a moment to clearly understand the arguments we took earlier from the user:

If you used --recreate, it drops all the tables, recreates them, and then loads your fixtures into fresh tables. This is helpful if you want to start from scratch every time.
If you used --truncate, it empties all rows but keeps the tables themselves (the structure stays intact), then loads your fixtures.
If you didn’t pass any of those flags, it simply inserts the fixture data as-is, without dropping or truncating anything.

The Conclusion

Do you think this could be done even better? Hmm that’s exactly why we’d love to have you join our Discord community! Want to see what we’re building and what we’ve accomplished so far? Take a look at our CHANGELOG.md.

Come help us shape the future of Nixopus a next-gen ServerOps management platform.

Happy Coding!

Don't Be a Foolish, Contributing to Open Source the Right Way

Raghav — Sun, 22 Jun 2025 13:30:14 +0000

Don't be a foolish

I know most people follow some great influencers. Wait let me put this another way :p Every influencer builds a set of people to follow them. This holds true across industries including ours software engineering. Influencers want attention. They want you hooked.

And truth be told, a lot of us are just... there for the taking. Like prey. You might be asking, "Why are you even talking about influencers?" Simple: don’t be a prey. Don’t get hooked just because someone told you to. Take what you want not what they want to sell.

Let me give you a small reality check, People have rushed into open source just to get goodies. Or to show off a contribution. Or flex open sourcing. And hey, I get it competition is tough. So now the real question is How do you stay smart and still stand out without losing yourself? Let’s move to the next part.

Be a gentlemen

We just saw what’s messed up. Now let’s flip that. Let’s talk about how to contribute meaningfully. And yeah, be one among the smart folks without acting like you know everything.

You think making changes to the codebase is the only way to contribute? That’s where most people go wrong. Open source isn’t just about pull requests. Let me break it down.

1. Replace your paid software with open source alternatives

Start with what you use every day phone, laptop, browser extensions, editors. You’ll be surprised how many open source tools are out there doing the job better than the paid ones.

For example: Instead of using some heavy VPS management dashboard, switch to something like Nixopus which is open-source, self-hostable, built by folks who understand what pain means. You’re not just saving money here. You’re supporting real engineers building real tools for the community.

2. Now that you’ve switched, show some gratitude

You replaced it. You’re using it. The least you can do? Star the repo. Maintainers don’t see your thank you tweets. But they do see stars. You didn’t pay for it. You didn’t file bugs. You didn’t contribute. At least star it?

It’s a simple way of saying :

3. If you’ve got money, don’t pay but sponsor

Yeah, I said it wrong. You’re not paying anyone. You’re sponsoring the effort. Projects have recurring costs. Time is money. And if you believe in the tool, why not put in a small amount every month? It doesn’t have to be big. Just enough to say, “I care.”

4. Spread the word

If you found something amazing, don’t keep it to yourself. Send it to a friend. Drop it in your dev Discord. Write a LinkedIn post. Tweet about how it helped you. We all love that little high when someone goes “thanks for suggesting this" right? Give others that chance too.

5. Found a bug? Got an idea?

Okay now it’s time to open GitHub or GitLab. But please don’t be that person who opens an issue like:

Follow the ISSUE_TEMPLATE if not found then do this:

Define the problem
Add the context
Share the steps to reproduce
Mention your environment
Suggest a solution if you have one

If it’s a feature, explain what you’re trying to do, and how this feature would help. Don’t just drop a one-liner and disappear. That’s worse than not reporting at all.

6. Know how to fix it? Do it right.

Let’s say you understand the issue and you have time to fix it. Here’s what you do:

Check the labels (good first issue, help wanted)
Make sure no one else is already on it
Look at the project board or discussions
Read the contributing guide
Set it up locally, follow formatting + linting
Run tests if they exist

Then create a clean PR with a clear title and message: Fix: Prevent Wizard Crash on First Login This PR adds a cleanup step to fix the onboarding crash issue. Ask for a review. Be open to feedback. Fix if needed. Wait calmly and boom, your code goes live. How cool is that?

You just followed the ideal path

Let’s pause and Look at what you just did You didn’t jump in just to rack up issues.You weren’t chasing a t-shirt or a contributor badge. You actually used the software, saw what was missing, felt where it hurt. You didn’t throw in a fix blindly rather you understood the context, took the time to figure things out.

This wasn’t about proving anything to anyone. No influencer told you to. No hype pulled you in. You did it because it made sense. Because the problem felt real. And because somewhere deep inside, you knew you could help.That’s the difference. That’s what makes it genuine.

Don't know where to start? Here's Nixopus

Check out Nixopus a modern, open-source VPS manager built for people who are tired of SSH'ing into every damn server just to restart a container or serve static files. It comes with everything you wish your hosting panel had from Docker support and TLS setup to a file manager, built-in terminal, and basic monitoring, all in one clean, self-hostable interface. Whether you’re managing a single server or juggling ten, it makes the whole thing a lot less painful.

And yeah, if you find a bug, or want to improve it, now you know exactly how to go about it.

Final words

Look open source isn’t a popularity contest. It’s a playground for creators, fixers, dreamers, and builders. Be intentional. Be helpful. Be respectful. You don’t need permission to start. Just don’t be a foolish.

Got thoughts? Share them. Got a story? I’d love to hear how you started with open source.

You Were Here All Along So Here's a Surprise

If you've been exploring Nixopus and thinking about getting a VPS to try it out, we’ve got something special for you.

We’ve partnered with Hostup, a fast and reliable VPS provider based in Sweden, to bring an exclusive deal to the Nixopus Community.

🎁 What’s the Surprise?

Use the code J9UYJCQBHL at checkout to get 10% off recurring on any VPS plan. Whether you're self-hosting with Nixopus, managing your own infrastructure, or spinning up Docker containers this is a great chance to start with solid, affordable hosting.

Go build something cool. The infra’s on discount.

The Gem of a Github Action you never used

Raghav — Sat, 14 Jun 2025 08:43:26 +0000

It's time I show you one of the coolest GitHub Actions we're using at Nixopus.If you're like me, you're probably more curious about the “why” than just hearing the solution QEMU.

So before diving into how we use QEMU, let me walk you through the why so the context is clear and the solution makes perfect sense.

Too Many Moving Parts: Why We Needed Emulation?

Nixopus is a platform that streamlines your entire VPS/server workflow. But deploying it wasn’t always smooth we hit a few bottlenecks that made us rethink our existing approach.

Here’s the situation, We offer a self-hosting one-liner installation script. This script handles:

Docker setup
SSH configuration
Proxy management
Bringing up Nixopus services (API, database, etc.)

Naturally, this raised a few critical questions:

How can we test this installation script every time we make changes?
How can we be sure it works across all major Linux distributions, regardless of their initial state?
How do we verify the script works with a matrix of different parameters?

The Obvious Solution You’d Think Of

If you're anything like me, your first instinct is to think of a quick fix, then improve upon it. So I started thinking in these directions:

1. "Let’s Write Unit Tests for Each Function?"

That was my first idea the classic starting point. But as you’ll soon see, it doesn’t really address the kind of problems we’re facing. Sure, unit tests are great. It’s tempting to think “Let’s just write a test for each function and run it on every change via CI/CD. Easy, right?”

"Sounds good in theory. But falls apart in practice."

Why? Because we're not just dealing with simple logic here we’re dealing with the full complexity of what our installer sets up. Now ask yourself : How do you unit test that without turning your test suite into a full blown Docker simulator Mocking all of that? At that point, you’re not testing your install script... you’re testing your mock environment.

And that’s when I knew unit tests alone weren’t going to cut it

2. "How about manually testing the installer before release?"

I figured if nothing else works, I’ll just set up a GitHub Action that SSHes into my VPS and runs the installer. I even explored appleboy/ssh-action to automate this through GitHub Actions.

Sounds promising, right? You could:

Run tests on every push
Validate the installer across multiple config permutations using matrix builds
Catch failures early

But here’s where it started to fall apart:

You need a dedicated VPS just for testing
How do you run parallel executions of the installer, especially when systemd is involved?
Want to test different distros? Well… you'd need a VPS for each one.

3. "Virtualization is the easy-peasy solution, right?"

At this point, the idea of spinning up virtual machines felt like a natural next step. We were close testing on a real VPS worked, but lacked multi-distro flexibility.

That’s when tools like HashiCorp Vagrant caught my eye. It provides a full-featured way to manage virtual machine lifecycles.

So in theory:

We dedicate one VPS for testing
Spin up VMs for each target distro
Run the installation script in each

Sounds solid. But then reality kicked in:

"Wait... aren’t we over-engineering this just to test an install script?"

Let’s be honest:

Do we really want to maintain VM lifecycle logic inside our CI?
Do we even have enough system resources on a single VPS to run multiple distros in parallel?

Now you might be thinking — "Why not just use containers?"

Yup. Same thought crossed my mind. But that idea died the moment I remembered

We’re dealing with systemd, low-level networking, service bootstrapping stuff containers just aren’t great at simulating. And that’s how we ended up looking at full system emulation...

The Life Saviour: QEMU GitHub Action from Docker

name: ci

on:
  push:

jobs:
  qemu:
    runs-on: ubuntu-latest
    steps:
      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

QEMU is a generic and open-source machine emulator and virtualizer.

After walking through all those pain points distro variations, systemd compatibility, real OS behavior, parameter matrix testing QEMU turned out to be the cleanest and most reliable solution.

And the best part?

It worked out-of-the-box without any fuss

What Did We Learn From All This?

You might be thinking “Why not just look at how other projects test their self-hosting installation scripts?” You're right that would’ve been the easier route. But here’s the thing: we’re not just blindly following others. We’re solving a real-world, reproducible problem with intent.

Others might have elegant test setups or they might be winging it behind the scenes.

What matters is the process we went through:

Hitting walls
Considering workarounds
Evaluating complexity vs. scalability
Finally arriving at a solution that fits our needs

And funny enough all of this, just to test a one-liner installation script 😂

But hey, that’s engineering.

If you know any better approach than this let's talk more and shape it out. if you are someone who is interested in such engineering take ups here we are Join our Community

How Docker Contexts Transformed My Multi-Environment Workflow

Raghav — Tue, 10 Jun 2025 17:09:27 +0000

One fine evening, I was working on my project Nixopus. Nixopus is a self-hostable application that puts an end to the chaos of traditional VPS management.. As part of the setup process, I had written a script to automate its deployment across different environments.

The Context of the Problem

Nixopus internally relies on Docker for running and managing its services, so the script had to ensure full and secure access to Docker on the host machine. Here's what it needed to handle across any environment:

Verify Docker installation — Check whether Docker was already installed on the server.
Install Docker if missing — Make sure to install docker and docker dependencies that are compatible.
Version compatibility check — If Docker is already present, compare its version with what Nixopus requires to ensure smooth operation.
Generate TLS certificates — Use openssl to create certificates that allow secure connections to Docker over TLS.
Configure Docker daemon — Modify the daemon.json file to:
- Use the generated TLS certificates,
- Enable secure communication,
- Bind Docker to the required network interfaces.
Validate Docker access — Reload or restart Docker using systemd (or another service manager) and ensure secure remote access works as expected.

The Chaotism Begins

I thought I was doing everything right — but then, one by one, problems began piling up like a stack. Let me walk you through the chaos:

Conflicting daemon.json setups
What if the user already had a daemon.json configured for their own purposes? Should we just go ahead and overwrite it with our custom setup?

At first, I naïvely said “yes.” And that’s when it hit me — we were doomed. Overwriting user configurations without merging or backing them up? A recipe for disaster.
No isolation between environments

What if I wanted to install Nixopus on the same machine for both production and staging? Docker doesn't support running two separate daemons bound to different environments by default. Suddenly, our clean setup felt too rigid. I needed some form of isolation that wouldn't require spinning up full-blown VMs or resorting to hacky workarounds.
Credential conflicts and confusion

Each environment had its own TLS certs and binding requirements. But trying to manage them manually — keeping track of which certs belonged to which context, ensuring the right IP was exposed — quickly became error-prone. One small mistake and I’d be locked out of Docker, or worse, end up exposing a production port unintentionally.

This is where things spiraled. Each new problem broke my illusion of control and made it clear: we needed a better, more structured way to manage Docker across environments — without losing sanity or safety.

And that’s when Docker contexts entered the scene - like a life saviour

Efficient Chaos Management with Docker Context

Docker Context lets me solve many of the problems I used to face in multi-environment Docker workflows. It brings isolation, simplicity, and clarity to the way I manage local, staging, and production setups.

With Docker Context, I can:

Isolate environments cleanly
Use different ports for different daemons
Configure environment-specific TLS certificates
Avoid the chaos of switching between shell exports, flags, or config files

And the best part? It’s really easy to use. No messy commands. No juggling environment variables. Just simple CLI instructions:

docker context create production 
docker context use production 
docker context ls

With these, I can switch between environments effortlessly, knowing that each one is securely configured and neatly separated from the rest

Have We Solved Our Docker Daemon Problem Yet?

While Docker Contexts make it easy to switch between different Docker environments from the client side, they don’t solve the problem of running multiple Docker daemons with separate daemon.json configurations. Docker still expects a single, global daemon.json file — there's no built-in way to maintain separate configs for different environments on the same machine

So how did i work around that?

Here’s the trick: instead of trying to juggle multiple daemon.json files, i used systemd service overrides. This allows me to run multiple Docker daemons, each configured with its own port, TLS settings, and data directory — without touching the default config.

With Docker Contexts handling the client-side switching and systemd overrides managing isolated daemon instances, I finally got true multi-environment control — clean, secure, and conflict-free.

What is Nixopus?

Nixopus is a self-hostable application that puts an end to the chaos of traditional VPS management.

Whether you're running multiple environments, deploying Docker containers, managing static sites, or just tinkering with servers for fun — Nixopus gives you a clean, powerful web interface to do it all.

No more memorizing commands, editing obscure config files, or SSH-ing into every box manually. With Nixopus, you can focus on what really matters: building your side project, running your business, or learning infrastructure at your own pace — without the stress.It’s open-source, community-driven, and designed for developers who value clarity, control, and simplicity.

Did You Know About Docker Contexts and This Hack?

Were you already using Docker Contexts or aware of this systemd override trick?

Or how do you usually manage these kinds of multi-environment challenges?

Maybe there’s an even better solution we haven’t thought of yet — and we’d love to hear about it.

At Nixopus, we believe in community-driven development. We're building a powerful, open-source VPS workflow manager — and solving real-world infrastructure pain points together.

If you're passionate about DevOps, automation, or self-hosting, join our community and help shape the future of server management.

Introducing Nixopus - All in one Open Source VPS Management Solution

Raghav — Tue, 29 Apr 2025 13:23:09 +0000

I'm a long-term VPS user, and I've been using VPS servers for various purposes over the last 5–6 years. Sometimes, though, managing a VPS feels unnecessarily terrible.
I know it can be tempting to think, "Well, isn't it your fault for not knowing how to manage it properly?" I see your point, and I have to admit that I do agree with you to a certain degree. But here's the thing: whether I'm a pro at managing a VPS or not, it should be a breeze!

TL;DR: Prefer a quick overview? 👉 Watch the Nixopus Demo

(You can always come back to explore the full details below!)

Control Panels & Tools

These days, I notice fewer people relying on traditional control panels — for good reasons.Tech-savvy users often prefer advanced, modern GUI tools, or they work directly through the terminal.

Take a simple example: when I want to host an application I've built, I usually have two options:

Set up a CI/CD pipeline (for example, using GitHub Actions), which requires configuring SSH keys, private access options, environment variables, and adapting pipelines as configurations evolve.
Or use self-hosting tools like Coolify.

Speaking of Coolify — it’s a great project. I personally admire its scope, have used it, and was even part of the Coolify Discord community.
However, Coolify primarily focuses on self-hosting capabilities. It's a fantastic choice if your goal is just that — self-hosting.

But as a user, I wanted more:

A powerful file manager,
A Google Cloud / AWS Cloud Shell-like experience,
A modern interface to manage my server, apps, and files — all in one place.

I wasn’t ready to install separate tools and manage them individually for each task.
That’s when I decided: Why not create something that combines all these needs into one seamless VPS management tool?

Introduction

Nixopus is your all-in-one platform to make VPS management simple, fast, and hassle-free. Whether you're a developer, system administrator, or just someone running your own server, Nixopus brings everything you need into one place — no extra setup, no messy configurations.

With Nixopus, you can:

Host your applications easily with one-click deployments,
Access a built-in terminal just like Google Cloud Shell or AWS CloudShell,
Navigate your server files with a modern, intuitive file manager,
Manage domains, TLS certificates, notifications, and more — all from a clean, simple dashboard.

No need to install multiple tools or stitch things together manually — Nixopus gives you everything you need to deploy, monitor, manage, and maintain your servers — right at your fingertips.

This is just the beginning — and as Nixopus grows, it's going to get even more powerful, with more features driven by community feedback and real-world needs.

Installation

To install Nixopus on your VPS, ensure you have sudo access and run the following command:

sudo bash -c "$(curl -sSL https://raw.githubusercontent.com/raghavyuva/nixopus/refs/heads/master/scripts/install.sh)"

Optional Parameters

You can customize your installation by providing the following optional parameters:

--api-domain: Specify the domain where the Nixopus API will be accessible (e.g., nixopusapi.example.tld)
--app-domain: Specify the domain where the Nixopus app will be accessible (e.g., nixopus.example.tld)
--email or -e: Set the email for the admin account
--password or -p: Set the password for the admin account

Example with optional parameters:

sudo bash -c "$(curl -sSL https://raw.githubusercontent.com/raghavyuva/nixopus/refs/heads/master/scripts/install.sh)" -- \
  --api-domain nixopusapi.example.tld \
  --app-domain nixopus.example.tld \
  --email admin@example.tld \
  --password Adminpassword@123

Accessing Nixopus

After successful installation, you can access the Nixopus dashboard by visiting the URL you specified in the --app-domain parameter (e.g., https://nixopus.example.tld). Use the email and password you provided during installation to log in.

Features

I'm excited to walk you through what Nixopus has to offer.
Let’s start exploring its features!

Self-Hosting

With Nixopus, you can easily host applications on your own server, manage them, and monitor them — all in one place.
Nixopus currently offers build packs for Dockerfiles and static sites.

I know, I know — you’re probably expecting even more options!
But remember, this is just an alpha release.
I intentionally chose not to build everything at once and publish it a year later — only to find out it doesn’t meet the real needs of users.
Instead, I want to grow Nixopus together with the community, one step at a time!

Nixopus' self-hosting capabilities also offer:

Easy to configure modern TLS, including modern ciphersuites, including out-of-the-box support for multiple signed CAs.,
GitHub integration — connect your repository and set up automatic deployments when you push changes to specified branches,
Easily configure and quickly redeploy configurations or even new instances of your applications.,
Application deletion when it's no longer needed.

With Nixopus, you don’t have to perform extra manual steps — it listens, builds, and updates for you.
Simple. Reliable. Developer-first. Know more

Powerful Terminal

When you log in for the first time, you’ll notice a terminal conveniently located at the bottom of the dashboard.You can toggle it easily — just like in enterprise tools such as Visual Studio Code — by pressing (Ctrl/Command + J).

This terminal is designed to offer a similar experience to working with Google Cloud Shell or AWS CloudShell, but with an eye toward even better, more elegant features in upcoming releases!

Thinking of a cool feature you'd love to see in the terminal?
You're more than welcome to contribute — come shape the future of Nixopus' terminal alongside fellow developers and make it truly your own!

File Manager

Nixopus also features a built-in File Manager.

You can access it easily from the sidebar — and from there, you know the basics: navigate, manage, and organize your server files intuitively. Currently, the File Manager is very basic, as the focus is on stability and core functionality, since this is still the alpha stage.

Needless to say, there are many useful features, developer-friendly add-ons, and a plethora of cosmetic updates on the roadmap.

8 More Features You’ll Love

Beyond the major features we covered earlier, Nixopus also offers a variety of powerful customizations and enhancements through its settings:

Dark/Light Mode — Easily switch between dark and light themes based on your preference.
Custom Fonts — Choose from a collection of cool fonts! (I’ll admit — picking the perfect font isn’t my strong suit — so I’ve made sure you can choose the one that suits you best!)
Language Selector — Prefer using software in your native language? Me too! (I'm a proud Kannadiga, so Kannada is already available!) Want to add your language or improve existing translations that feel robotic? Let’s collaborate and make it truly human-friendly!
Two-Factor Authentication and SSH-Based Connections to Your Server — When it comes to security, I personally want Nixopus to include many best practices and security-related features — because we are exposing our server on the web, right!
Team Management & Auditing — You can add team members, manage permissions, and track activities. (Yes, we already have an auditing system that logs who did what and when!) More advanced team and organization features are planned for the beta release — stay tuned!
Domain Management — Add and verify your domains right inside Nixopus. This makes it seamless to connect your domains while self-hosting your apps.
Smart Notifications — Choose the types of notifications you want to receive, and get alerted via Email, Slack, or Discord — your choice!
Auto-Update — Stay up to date effortlessly! You can either enable automatic updates when we release new features and fixes, or manually trigger updates with a single click from the dashboard’s top-right corner.

The features you see today are just a glimpse of Nixopus' true potential.
Stability, power, and polish will come from refining these features — and yes, by writing beautiful, robust tests along the way!

What’s Coming Next?

I know you’re probably even more excited than I am — so let’s talk about what’s next!
My goal is to make Nixopus truly enterprise-ready and stable as a VPS management solution.

Here are a few key areas I’m focusing on:

Security best practices — High importance (Security is absolutely critical. Expect this to be a top priority.)
Polish and production-grade stability — High importance (Making Nixopus rock-solid, well-tested, and reliable for real-world deployments.)
Multi-server management — Medium importance (I want you to connect and switch between multiple servers easily.)
Config/Script Marketplace — Medium importance (A place where you can find and share scripts/configurations. I’ll write a detailed post soon explaining what it is and why I believe it’s needed.)
Community-driven development — Extremely important (I don’t want to build Nixopus in the dark. Every developer has different perspectives — you might love a feature I don’t, or dislike something I love. That’s the beauty of building together.)

Show Your Support

Nixopus is meant to be community-driven, and for that, I kindly ask for your support.I’m fully aware that the current alpha release has rough edges — and that’s intentional.Rather than hyping it as “production-ready” when it’s not, I chose to release early to gather honest community feedback.

This is your chance to shape Nixopus!

You can help by:

Starring us on Github
Sponsoring
Contributing,
Sharing it with your friends,
Or even telling the harsh truths — if you didn’t like something, I want to hear it.

Every word, every contribution, every opinion matters — and it’s all welcomed with open arms.

Conclusion

Most readily available comparable products on the market are limited, not developer-friendly, or very user-unfriendly in terms of price and availability. Apparently, there is a huge gap and problem that Nixopus as a project is trying to address.

Nixopus is community driven, developer friendly and constantly evolving. With a few private deployments, including by friends, the amount of usable feedback is turning Nixopus into a truly modern server management tool with features that server admins are really looking for.

Join the community