From self-hosted LavinMQ to a managed LavinMQ in CloudAMQP

LavinMQ is open source, fast to get started with, and easy to run on your own. For many teams, self-hosting is the natural first step.

But as systems grow and messaging becomes critical infrastructure, running a broker stops being just a setup task and turns into an ongoing operational responsibility.

In this blog post, we’ll look at what self-hosting LavinMQ really involves, when it makes sense to do it yourself, and why many teams eventually move from a self-hosted LavinMQ to a managed LavinMQ on CloudAMQP.

You can clone the LavinMQ repository build it, and have a fully working message broker running on your own machine in minutes. You can connect producers and consumers right away and watch messages move through the management UI.

So if it’s open source, why wouldn’t I just self-host it?

That was exactly how I thought at the beginning, and it’s a fair question. Running your own broker feels straightforward, especially early on. But the simplicity you see at the start isn’t the whole story.

What self-hosting really means

Self-hosting a message broker starts with setup: installing it, confirming it runs, and connecting applications. That part is usually easy.

For example, you can start a LavinMQ broker locally using Docker with a single command:

docker run -d \
  --name lavinmq \
  -p 5672:5672 \
  -p 15672:15672 \
  cloudamqp/lavinmq

Or you can install it directly on a server by downloading a release binary, configuring a service, and starting it like any other system daemon. You can also clone the repository and build it from source if you want full control.

All of these approaches give you a fully functional broker that works exactly as expected. Within minutes, you can connect producers and consumers and watch messages move through the management UI.

Once it’s running, the responsibility shifts to you.

Now, you’re responsible for patching the operating system, keeping an eye on disk usage, managing users and permissions, rotating certificates, planning upgrades, and making sure monitoring and alerts actually fire when something goes wrong. Availability, failover, and incident response all become part of your job as well.

Open source doesn’t make this work disappear. It simply moves the cost from licensing to responsibility.

The higher cost isn’t setup time, it’s ongoing time. Time spent chasing potential disk warnings, tuning memory limits and file descriptors, reading release notes before upgrades, scheduling maintenance windows, and testing backups you hope you’ll never need. None of this is optional if the broker is part of a production system. That time comes directly out of engineering focus. Every hour spent maintaining brokers is an hour not spent building. In real systems, you rarely stop at one broker. As systems grow, brokers get split by region, workload, or team. Each additional broker quietly adds more work: more servers to manage, more storage to monitor, more backups to verify, and more things that can fail.

Before long, the technical questions turn into operational ones.

Who gets paged when the disk fills up at three in the morning?
Who verifies that backups actually restore correctly?
Who upgrades the broker without losing messages?
Who designs and tests high availability?

Open source gives you the code. It doesn’t give you on-call coverage, operational guarantees, or tested recovery procedures. Those responsibilities still belong to you.

The initial question is often, why wouldn’t I just self-host it? Over time, that question shifts to something else: do we really want to run and maintain this ourselves?

When managed messaging starts to make sense

Moving from a self-hosted broker to CloudAMQP doesn’t change how your application works. The protocol stays the same. Client libraries stay the same. Producers and consumers behave exactly as before. From the application’s perspective, nothing fundamental changed.

Message brokers stop being something you run and become something you simply use.

Planning upgrades, managing backups, watching disk growth, tuning limits, and setting up monitoring are no longer things you actively worry about. That work still exists - it’s just handled by CloudAMQP, whose entire job is to run message brokers reliably.

Choosing between self-hosted and CloudAMQP

This isn’t a question of right or wrong. It’s a question of trade-offs.

Self-hosting makes sense in many cases. If you’re learning how message brokers work, experimenting with architectures, or already operating everything yourself, running your own broker can be a good and even educational choice. You get full control and a deep understanding of the system.

But self-hosting also means accepting that message brokers are part of your operational burden. As expectations around availability and reliability increase, that burden grows. What starts as a simple setup can slowly turn into a meaningful commitment.

Managed services like CloudAMQP become attractive when the cost of that responsibility outweighs the benefit of direct control. When reliability matters, when multiple brokers are involved, or when engineering time is better spent building product rather than maintaining infrastructure, outsourcing broker operations becomes a practical decision.

At that point, the choice isn’t really about software. It’s about focus.

If you’re running a self-hosted LavinMQ cluster and want to migrate to a managed cluster on CloudAMQP, you don’t have to start from scratch.

The migration process is very similar to migrating between managed RabbitMQ clusters. You can follow this step-by-step guide to move messages with minimal disruption:

How to migrate between RabbitMQ plans using queue federation