A Year Later in Another Self-Hosting Journey

In late 2025, we started thinking about migrating some of the services we rely on daily to our own infrastructure. Before the end of the year, GitLab and OneDrive were some of the services we decided to replace with self-hosted alternatives.

Although this might sound like a significant change for an organization accustomed to cloud-based services, self-hosting is nothing new to us¹. We have been operating our own infrastructure for some time, including email, CDN, and security services. However, as our organization continued to grow, we started questioning how much of our daily operations should depend on external providers.

The goal was not to replace services with self-hosted alternatives, it was about gaining greater control over our infrastructure, reducing costs, improving privacy, and building an environment that better suits our values and needs.

After a year of running these self-hosted services, we’ve learned a few things about the advantages and challenges that come with self-hosting. More importantly, we have managed to reduce our costs by approximately 70%.

Why to self-host?

There are several reasons behind this decision, but two stand out: increasing operational costs and the desire for greater control over the tools.

As our team grew, so did our usage of third-party services. What initially starts with a reasonable subscription gradually becomes a more significant recurring cost.

At the same time, we noticed that the services we depended on were evolving in directions that did not necessarily align with our preferences or workflows. We wanted to change that.

Self-hosting offered us the possibility of maintaining the same essential functionality while having more freedom over configuration, updates, integrations, and infrastructure decisions.

This also means taking responsibility for their availability, maintenance, backups, and resource management. We understood that this would require additional work, but we considered that trade-off worthwhile.

GitLab: More control over our development infrastructure

One of our main motivations for self-hosting GitLab was the increasing demand our development team was placing on CI/CD.

We had previously been using GitLab SaaS and paying for the service. As the organization grew, our CI/CD requirements increased, so did the amount of money spent on the platform.

CI/CD is an essential part of our development workflow. Having greater control over runners, pipelines, resources, and configuration became increasingly important.

The interface changes introduced with GitLab 18.6 was also a factor that influenced our decision. In our opinion, these changes represented a step backwards in terms of usability, readability, and accessibility. We understand that interfaces evolve and that different users have different preferences, but we felt that the new direction did not work particularly well for our team’s workflow.

This reinforced an idea we had already been considering: why should we have to adapt our daily development environment to decisions made by a provider when we could operate our own instance?

We started exploring our options and eventually decided to deploy GitLab Community Edition (CE) 16.5.8. It provided the core Git repository management and development workflow capabilities we needed, while giving us considerably more control over the environment.

Our deployment consists of GitLab CE running on our own infrastructure, with GitLab Runners operating on the same machine. This approach allowed us to consolidate our development infrastructure without introducing additional machines or unnecessary complexity.

All this, as a trade-off, requires regular maintenance, monitoring, backups, updates, and careful resource management. CI/CD workloads can also be particularly demanding, especially when several pipelines execute simultaneously.

Seafile: Replacing OneDrive with our own collaborative storage

GitLab was not the only service we wanted to bring under our control, we also wanted to establish our own collaborative file storage and sharing environment, replacing our dependence on OneDrive.

For this purpose, we chose Seafile, a self-hosted file synchronization and collaboration platform.

Cloud storage is incredibly convenient, particularly when multiple people need to collaborate on documents, share files, and access information from different devices.

However, convenience often comes with compromises. Depending on an external storage provider means trusting that provider with our organization’s files, metadata, access policies, and potentially sensitive information.

For an organization that already operates much of its own infrastructure, moving collaborative storage in-house was a natural next step.

Seafile allowed us to establish our own environment for storing, synchronizing, and sharing organizational files without depending on OneDrive.

This brought several advantages such as greater control over our data, more privacy, and independence.

Of course, privacy is not automatically guaranteed just because a service is self-hosted. Proper configuration, access management, backups, and ongoing maintenance remain essential. The important difference is that we have greater control over how these things are implemented.

Self-hosting as more than just saving money

One of the most interesting things we learned through this experience is that self-hosting should not be evaluated exclusively in terms of subscription savings.

At first glance, replacing a SaaS subscription with a self-hosted deployment might seem like an obvious financial decision. However, infrastructure has its own costs.

Hardware, electricity, connectivity, storage, backups, maintenance, monitoring, and the time required to operate everything must all be considered.

There is also the cost of responsibility; when using a managed service, much of the underlying infrastructure maintenance is handled by the provider. When self-hosting, that responsibility becomes yours.

You are responsible for ensuring that services remain available, that data is backed up, that updates are properly managed, and that unexpected problems can be resolved.

All this gives us independence, flexibility, and a better understanding of the systems our organization relies on every day.

It also means that we can make infrastructure decisions based on our own requirements rather than being entirely dependent on the priorities and product roadmaps of external companies.

A year later: was it worth it?

After a year of operating these services, we can say that self-hosting has reinforced our confidence in maintaining more of our own infrastructure.

We managed to replace two important external services, establish our own development and collaborative storage environments, and reduce the associated costs by approximately 70%.

There are certainly additional responsibilities involved such as maintenance, monitoring, backups, resource management, and capacity planning are not things that can be ignored.

But these responsibilities are also part of operating reliable infrastructure. The difference is that we now have a more direct role in managing it.

For BBJProjeK, this experience represents another step towards a more independent and privacy-conscious infrastructure.

We do not believe that every organization should abandon SaaS platforms or start self-hosting everything overnight. Managed services have their place, and there are situations where they are the most sensible option.

However, we do believe that organizations should periodically evaluate how much they depend on external providers and whether those dependencies still make sense.

Sometimes, the best solution is not another subscription. Sometimes, it is building and maintaining the infrastructure yourself.

Our journey towards greater infrastructure independence is far from over.