This post will be fairly technical. If you only want to know how these changes will affect you, you can skip directly to the “How does this affect me?” section. For anyone interested in the background and reasoning behind the decision, here is the longer version.

MCVHost is an independent business that was created almost by accident in 2016. Since then, I have been responsible for practically everything: developing new features, operating the infrastructure, handling customer service and technical support, and almost anything else that happens somewhere in between.

Those ten years have left me with two important things: a highly automated system and a considerable amount of technical debt. Some parts of the platform were written when I did not yet have the experience I have today to properly evaluate the long-term consequences of certain technology choices. Important parts of AutoMCC, which currently participates in managing radio services, databases, TeamTalk servers, and web hosting, still depend on a web framework that is approaching the end of its officially supported life.

That does not mean the system is about to stop working. After so many years working with it, I know its limitations, edge cases, and internals quite well. The real problem is elsewhere: this dependency forces us to keep very specific versions of software and operating systems in place, while also keeping parts of the platform tightly coupled when they should be able to evolve independently.

That is exactly what I want to change.

Over the next several months, a number of things will be happening at the same time. The most important change from a customer perspective is that I will be separating services according to the role they perform.

At the moment, almost everything passes through a single central panel. That system is responsible for creating TeamTalk servers, changing their configuration, starting and stopping them, creating and managing databases, provisioning web hosting, and handling all of the tasks related to radio services.

At the time, this architecture made sense. AutoMCC already solved a large part of the problem, and whenever a new requirement appeared it was tempting to think, “I already have a system that works, so this is just one more responsibility.”

The problem is that “just one more responsibility,” repeated enough times over enough years, eventually becomes too many responsibilities inside the same system. That is exactly where we are today.

There is now too much dependence on that central panel. If it becomes unavailable for any reason, a significant part of the platform’s operation is affected: TeamTalk servers, databases, web hosting, and many of the tasks required to operate radio services can no longer be created or managed normally. This makes the panel a critical dependency in the platform.

Fortunately, we have not had a major incident caused by this dependency, but I am no longer comfortable with so many unrelated functions depending on a single application, particularly when that application also carries technology decisions that are becoming increasingly difficult to maintain.

The goal of the new architecture is to reduce that dependency by separating each type of service into its own application. In practice, there will be one system dedicated exclusively to TeamTalk, another for web hosting and databases, while AutoMCC will become focused solely on radio stations again.

This separation has several advantages. If one of the three applications needs to be updated to add a new feature, we can do so without unnecessarily affecting customers who use unrelated services. Similarly, if one system encounters a problem, the others can continue operating independently.

The idea is simple: a change or incident involving TeamTalk should not have to affect a radio station, and a change to web hosting should not require touching AutoMCC. From the customer side, however, these services will still be managed through MCVHost.com or AutoMCC as appropriate, without requiring users to learn several unrelated control panels.

The separation also allows us to apply different security measures depending on the type of service being operated. Not every part of the platform has the same requirements. A web hosting service that executes customer-provided PHP code requires a much stronger level of isolation than an audio streaming service whose execution environment is controlled by the platform itself.

For that reason, web hosting will use stricter isolation between customers, while other parts of the platform can use a simpler model appropriate to their actual risk profile. This avoids two problems at once: adding unnecessary complexity where it provides little benefit, while also failing to provide strong enough boundaries where they genuinely matter.

All of this also requires changing how many of these services are run internally. Until now, some parts of the platform have shared more environment, dependencies, and deployment decisions than I would like. The new architecture is designed to give each service much more control over its own dependencies, versions, and update cycle.

I do not want to turn this post into a complete explanation of permissions, internal processes, or deployment mechanics, because I would probably lose a fair number of readers who have somehow made it this far. The important part is that each service will be able to run inside the environment it actually needs, without forcing the rest of the platform to inherit the same constraints.

For example, a change required to support a new version of PHP should not require me to modify anything related to radio services. Likewise, updating Liquidsoap should not have consequences for a TeamTalk server.

It sounds fairly obvious when written that way. Making it happen after almost ten years of growing a platform around a shared core is slightly more entertaining.

Where are we now?

This work will not happen all at once. The first service I have completely separated is TeamTalk. Its management now runs as an independent service and can be deployed, updated, and maintained without directly depending on the rest of AutoMCC. I expect to put it into production next week.

The next areas will be web hosting and the radio platform. Web hosting represents one of the largest changes because it is also where stricter customer isolation matters the most. The radio platform, on the other hand, needs to preserve much of the automation that AutoMCC already provides while removing responsibilities that never really belonged in a system originally designed to manage radio stations.

The final goal is for AutoMCC to return to doing primarily what it was created to do: manage radio services.

How does this affect me?

Most day-to-day management will still happen through MCVHost.com and AutoMCC, so you will not need to learn three different control panels or worry about how the services are connected internally.

There will, however, be some visible changes.

One of the most important will be SFTP access. Files related to web hosting and files used by radio stations will no longer share the same access credentials. Each customer will have at least two separate SFTP access points: one for web hosting, and another for files and content related to radio services.

This follows the same principle as the rest of the new architecture: each type of service should have its own environment, permissions, and lifecycle.

It will also be possible to create additional virtual users for either type of service. For example, you will be able to give someone access only to the files belonging to a radio station without also granting access to your web hosting, or create separate credentials for collaborators, applications, or specific workflows.

I will publish the exact details of how these accounts, paths, and permissions will work once the corresponding migration is ready for production.

Outside of these changes, the goal is to keep the overall experience as stable as possible. MCVHost.com will remain the main administration point, while AutoMCC will continue to handle radio management.

Most of the changes will happen behind those interfaces: more independent services, updates with a smaller blast radius, and clearer boundaries between different types of hosting.