Forem: Nixopus

Inside Nixopus: How We Manage Our Database Migrations?

Shravan Kumar B — Fri, 27 Jun 2025 13:44:31 +0000

This article mainly focuses on laying out our foundational approach to setting up the database migration system for Nixopus.

Database migrations are often the unsung heroes of software application development. They work silently in the background, ensuring that your database schema evolves safely alongside your application code. Yet for many teams, this is a major source of stress and uncertainty. In this blog, we will explore how we have set up the migration framework for Nixopus. This has become a pivotal step in our developmental and self-host workflow.

To start with, let us first explore and understand what we mean by database migration. As we always do, let us take an analogy.

We often use different database systems like MySQL, PostgreSQL, MongoDB, etc, for data persistence. These data are stored in the form of Tables having columns and rows.

As the application grows, the number of tables grows, and the data defined at each table might vary and change; hence, it is very important to keep track of these changes.

Tables are at the database system level, whereas at the programmatic level, we maintain them with something called schemas. Like a house blueprint that dictates where rooms, doors, and wiring go, a schema simply defines how the data is organized and connected.

Now, let's imagine that you decide to change the blueprint mid-build, to add a new room or window, you need to carefully make changes to the existing blueprint such that you don’t end up collapsing the walls down.

This problem is addressed at the schema level to ensure the changes in the existing tables, which may be in the form of adding new columns, altering the type of existing columns, or adding new tables, are handled through what we call Database Migrations

When we started building Nixopus, we quickly realized that database schema management would be critical to our success in self-hosting and local development setups. We planned with an expectation set that eventually we would see multiple developers working on different features, frequent deployments, and the need to support both development and production environments, which would require a very streamlined process to handle database migration.

We had aligned on the following factors that our migration system would have to adhere to:

Reliability: Migrations must execute consistently across all envs
Automatic: No manual intervention should be required during deployments
Forward & Backward Compatible: Ensure easy rollback scenarios
Separations of Concerns: Organization of migrations by domain or feature

Many existing tools either lacked the flexibility we needed or came with unnecessary complexity, be it in terms of testability or adding rollbacks in case of errors, etc.

Hence, we decided to build our migration system tailored to our needs and requirements using a tool called Bun ORM.

To those who are not aware of the terminology ORM, let me give a glimpse of it; ORM, otherwise called as Object Relational Mapper, is like a waiter at a restaurant, to who you tell what you want, he/she goes to kitchen(I mean database), then brings back your order(data) as perfectly plated objects in ready to use form.

Without ORM, you would have been presented with raw vegetables and ingredients straight from the kitchen (of course, by that I mean the database), and you would have to do all the cooking yourself, which means writing and managing every query and data transformation.

Coming back, we have built our migration system around a simple yet powerful concept, where a pair of SQL files represents every database change:

1) Applying the change (up migrations)
2) Rolling it back (down migrations)

This approach has helped our system to easily take care of schema evolution and database versioning.

The migration system follows a defined life cycle:

1) Discovery: The system scans the api/migrations directory

2) Parsing: Migration files are parsed and paired (up/down migrations)

3) Ordering: Migrations are sorted by their numeric IDs

4) State Check: The system compares file system migrations with applied migrations in the database

5) Execution: Pending migrations are executed in transactions

6) Recordings: Successfully applied migrations are recorded in the migration table

Now that you know an overview of our setup and how it works, you might wonder what actually sets our approach apart? Fair enough!!!!

1) Domain Driven Structure: Instead of throwing all migrations into a single directory, we have organized them by domain:

api/migrations/
├── applications/   # App deployment features
├── audit/          # Audit logging and compliance
├── auth/           # Authentication & authorization
├── containers/     # Container management
├── domains/        # Domain and DNS management
├── feature-flags/  # Feature toggle system
├── integrations/   # Third-party integrations
├── notifications/  # Notification system
├── organizations/  # Multi-tenancy & organizations
├── rbac/           # Role-based access control
└── users/          # User management and profiles

This structure makes it easy for us to find and create migrations related to specific work or flow, helping us avoid confusion or conflicts.

2) Automatic migration execution on application startup: One of the key design decisions was to make migrations completely automatic. When the application starts, the migration system runs before any other initialization. This approach eliminated the need for separate deployment and ensures that the database schema is always up to date when the application starts.

3) Atomic, Transactional Migrations: Every migration runs inside a database transaction, ensuring atomicity. If any part of a migration fails, the entire migration is rolled back, ensuring that the schema remains fully consistent.

4) Bidirectional Migrations: Every migrations have 2 files:

seqno_entity_up.sql (applies the change)
seqno_entity_down.sql (rolls back the change)

This ensures that we can always roll back changes if something goes wrong.

As we are close to concluding the deep dive into the first of many articles of the Inside Nixopus series, I would like to highlight some of the major learnings and key takeaways:

1) Keep each migration small and focusedfor easier review or rollback.
2) Ensure to keep a down migration for every up migration, ensuring roll backs are easy.

The key insight is that sometimes the best tool is the one you build yourself. By understanding our specific needs and constraints, we were able to set up our migration system that fits perfectly into our development workflow and easy self-hosting.

The project, as we publish this article, is in the Alpha stage.

You can check it out on GitHub and see for yourself.

To sum it up, the approach helped us change schema changes from a headache to a reliable process.

If you would like to get involved or have questions, join our Discord community for real-time support and feedback. You can self-host Nixopus today, subscribe for updates, and stay tuned as we roll out new features and stability enhancements.

We have recently collaborated with HostUp, a reliable VPS provider based in Sweden, to bring you an exclusive deal of 10% off recurring on any VPS plan. Whether you choose to self-host Nixopus or deploy containerized apps, this is the perfect opportunity to secure rock-solid infrastructure at a Discord Community.

Stay tuned for more freshly brewed content.

That's all for now. Thank you for reading.

Signing off until next time.

Thank you.

nixopus / nixopus

Open Source Alternative to vercel, heroku, netlify with simplified workflows

Open Source alternative to vercel, heroku, netlify with Terminal integration, and Self Hosting capabilities

Website • Documentation • Blog • Discord • Roadmap

⚠️ Important Note: Nixopus is currently in alpha/pre-release stage and is not yet ready for production use. While you're welcome to try it out, we recommend waiting for the beta or stable release before using it in production environments. The platform is still undergoing testing and development.

Features

Deploy apps with one click. No config files, no SSH commands.
Manage files in your browser. Drag, drop, edit. Like any file manager.
Built-in terminal. Access your server without leaving the page.
Real-time monitoring. See CPU, RAM, disk usage at a glance.
Auto SSL certificates. Your domains get HTTPS automatically.
GitHub integration. Push code → auto deploy.
Proxy management. Route traffic with Caddy reverse proxy.
Smart alerts. Get notified via Slack, Discord, or email when something's wrong.

Installation

…

View on GitHub

Nixopus: Simplifying VPS Management

Shravan Kumar B — Mon, 23 Jun 2025 18:03:39 +0000

This article is my reflection on the journey of how I relied on free tier clouds and platform specific hosting until I discovered VPS.

Shipping Code while Sipping Coffee

Back then, I was still trying to figure out and understand how all this worked. Starting from which command did what, which service refused to start, and why things that worked on my local; didn’t work when deployed (Thank God for Docker)

I still recall one of my earliest deployment. It was github-readme-quotes app on Heroku. A simple git push to deploy felt magical. I didn’t really have to care how it worked. I just knew that if I followed the documentation devoutly, it was assured to work; if not, StackOverflow always had my back.

This was the same with Firebase, Render, or Netlify for static stuff. All of them taught me how to ship quickly.

But then came the real world; need to host private apps, things that need ports, memory tuning, background workers, cron jobs, etc. Soon, those magical platforms started speaking back and complaining to me:

"You can’t bind that port"
"You’re out of free dynos"
"Exceed dynos quota for the month"

I found myself stuck on an architectural impasse till the day when one of the engineers I know suggested saying these lines, “Just spin up a VPS“. That advice removed the roadblock.

To those who are not aware of what is VPS? How is it different from Server? Let me try to explain it with an analogy:

Imagine you’ve built a website and now you want to make it public, so you need to host it. Basically put it out on a computer that is always online. This is called hosting.

Before hosting a website, there are 3 types of hosting, each of which balances cost, control, and performance in its own way. Let us take an analogy of hosting with where we live:

Shared Hosting is like renting a room in PG, which is extremely affordable, but you share your resources with others and have very little control
Virtual Private Server (aka VPS) is like having your own apartment, you get private space, you are secure, decorate and customize as you want, and truly call your own.
Dedicated Server is like leasing an entire bungalow; you alone enjoy all its resources and full autonomy at a very high price.

Dedicated Servers are either some crazy big computers in freezing cold data centers or virtual computers carved out of bigger machines using virtualization.

So, yep, VPS was that sweet middle ground; cost of a simple 1 BHK flat with freedom to knock down a wall (just kidding). So that balance I needed came in the form of VPS.

So I picked a VPS provider, bought a VPS server for 7€ (~₹697). I got an IP address, username(root), and SSH details.

Till then, I had learnt what VPS was and lil about behind the scenes from the few Google searches I had done. I understood that a VPS is a virtual machine running on a larger physical server with its own dedicated RAM, disk space, and CPU. And fortunately, since I was already comfortable with Linux commands, so felt navigating this environment shouldn’t be a problem.

Since I had previously tinkered quite a lot with Raspberry Pi, by hooking it to the local network and SSH’ing into it from my laptop, I already knew that the only way to connect to my VPS was using SSH.

To those who do not know what SSH means, let us again explore it with an analogy:

SSH is like a passport to access your VPS. With SSH, you can remotely step inside your VPS like teleporting into a distant terminal. It was like I’d opened the door to another computer without leaving mine. There is no UI, browser, but a simple terminal access for your VPS and raw power.

Every server I touched so far ran Linux, so I already had a clear cut understanding. So for everything looked good.

I started slowly moving my apps to the VPS, and running the scripts to have it run on the VPS. I ran into another hurdle; I was only able to access the deployed applications or services using their IP address, like http://123.45.67.89. Unlike Heroku or Netlify, which provided me ready made subdomain for a project like [github-readme-quotes.herokuapp.com], my move to a VPS setup left me staring at a bare IP address.

I knew I needed a proper name and URL, some-project.com, and that’s where DNS comes in.

To those who do not know what DNS is, consider it as a Internet’s Yellow Page (Phonebook); basically translates domain names to IP addresses.

A lot of them still find tying a domain to a VPS surprisingly tricky. Hence, I keep a simple recipe:

1) You buy a domain from Domain Registrar
2) Point it to your VPS IP using A records in your registrar’s control panel

Type: A  
Host: @  
Value: 123.45.67.89

3) Set up Nginx
4) Configure SSL

You might be wondering, what are these Nginx and SSL? Let us understand this better, diving a little deeper into the concepts.

Every service on your server or computer communicates over a specific port; some of them are already predefined, say:

SSH on port 22 for remote access
HTTP on port 80 for unencrypted web traffic
HTTPS on port 443 for encrypter web traffic via SSL/TLS

By now, you must have understood that SSL/TLS is what turns ordinary HTTP into secure HTTPS, making sure that the data between user and server stays private and secure.

Nginx is the traffic police on my VPS which is mainly responsible for forwarding user requests to respective applications, handling SSL encryption, and serving the static contents.

You must be wondering, "Voila, Great, now that everything is in place, and the hard part is over, life must be easier".

Hahaha!! Well, thats exactly when the real problems began. Over time, deployments process became a familiar and routine; rather painful routing I would say.

This routing masked a lot of headaches: broken configs, panicky Nginx configuration tweaks, dread thought of “Did I actually run the right script?“ and manual responsibility of deploying all of these without any automations and verifying the releases.

Eventually, I scripted it all, but I can never forget those initial days of manual, shaky deployments. They taught me the cost of carelessness, where I had spent a day to find one config misplaced. It wasn’t about skill, but rather about mental tax caused due to this.

By then, I had realised managing multiple applications on a single VPS only made things worse, where I had to juggle and handle process monitoring, checking the logs, and mainly running update scripts.

With power comes great responsibility

With experience comes great clarity; I started seeing patterns in the process I followed. I’ve been doing this for a while now, everytime I spun up a VPS or deploy new project on a VPS, I found myself re-Googling the same 20 commands. I observed that across some major pain points:

Copy-pasting Identical configurations
Deployment failures
DNS setups
Setting up Firewall rules
Forgetting about SSL renewals

It was the same story day in and day out. That is when I asked myself, is this problem not actually solved and standardized yet? Do we not have a tool that streamlines and simplifies the VPS management?

My search led me to Nixopus, an indie tool built by a community led by Raghav to tackle these exact frustrations. As we talked, it became clear that Nixopus wasn’t born from ambition rather from fatigue, the kind that drives you to refactor your life. It promised everything I had been hunting for.

Though in Alpha stage, I’ve started using it for managing my VPS and even actively contributing to improvements whenever I can. I am convinced that this project has a bright future. You check it out on GitHub and see for yourself.

We have recently collaborated with HostUp, a reliable VPS provider based in Sweden, to bring you an exclusive deal of 10% off recurring on any VPS plan. Whether you choose to self-host Nixopus or deploy containerized apps, this is the perfect opportunity to secure rock-solid infrastructure at a Discord Community.

You can claim your VPS coupon and start building with Nixopus today.

Join our Discord community, you’re always welcome to hop in for community support!

Summing it up, my journey from building on free-tier clouds and shared hosting to fully embracing VPS has taught me one thing is that having control doesn't have to mean endless repetitive manual work and management. Nixopus bridges that gap, so that from now on you can focus on what really matters.

Stay tuned for more freshly brewed content.

That’s all for now. Thank you for reading.

Signing off until next time.

Happy Learning!!