Internal platform: GitLab, Kubernetes, Coolify or Dokploy
The foundation your team builds and deploys on, set up in your account, as code and with a procedure so anyone can publish a new service.
Usual tools
- Coolify
- Dokploy
- Gitea
- GitLab
- Kafka
- Keycloak
- Kubernetes
- Hetzner
In short
An internal platform is the set of tools your team uses to store code, build it and deploy it without asking for help. We set up self-hosted GitLab with runners and registry, a Kubernetes or k3s cluster, or a self-hosted PaaS such as Coolify or Dokploy when Kubernetes is too much. Everything stays in your account, as code and documented.
- Languages
- Spanish, Catalan or English
- Response
- The next business day, during business hours
- Method
- In your account and your repository, in code and documented
What is included
- Chosen architecture in writing, with the reasons and the alternatives ruled out.
- Self-hosted GitLab with runners, container registry and object storage, if it fits.
- Kubernetes or k3s cluster, or a PaaS with Coolify or Dokploy, deployed as code.
- Template for publishing a new service: pipeline, deployment, domain and certificate.
- Platform backups with a tested restore.
- Basic monitoring of the platform itself.
- Technical team access through a WireGuard VPN, with one key per person.
- Documentation and a handover session with the team.
When do you need an internal platform?
When deploying depends on one person or on an outdated document. These are the most common signs:
- Each project is deployed in a different way and only one person knows how.
- The in-house GitLab or Gitea has not been updated in years and nobody wants to touch it.
- Cloud CI minutes or per-user licences have become a significant cost.
- You want to stop depending on a commercial PaaS and have your services in your own account.
- Each of the agency’s clients has a server set up by hand.
Kubernetes, k3s or a self-hosted PaaS?
There is no single answer: it depends on how many services you have, how many environments you need and who is going to maintain it. This is the comparison we usually make with each team:
| Option | Fits when | What it asks in return | What it does not do well |
|---|---|---|---|
| Managed Kubernetes (EKS, GKE, AKS) | Many services, several environments and high availability | Kubernetes knowledge and keeping an eye on cost | Two-person teams with three applications |
| k3s on your own servers | Kubernetes on Hetzner or another provider without a managed service | You maintain the control plane and the upgrades | Scaling to dozens of nodes without further design |
| Coolify or Dokploy | Few applications, one or two servers, small team | Accepting its networking and high availability limits | Fine-grained security policies and multi-cluster |
| Docker Compose with CI | One or two stable applications | Discipline in the pipeline and the backups | Zero-downtime deployments and autoscaling |
The recommendation is put in writing, with the reasons. If Kubernetes is too much for your team, we will tell you.
What do we set up with GitLab?
When the platform revolves around self-hosted GitLab, we take care of the pieces that usually cause trouble: runners with caching and scaling, the container registry with automatic image cleanup, object storage for artefacts and packages, single sign-on with your identity provider and backups with a tested restore. We go into detail on the managed self-hosted GitLab page.
The technical team’s access to dashboards, databases and internal servers goes through a WireGuard VPN, with one key per person that can be revoked instantly, and no admin ports open to the internet.
How does the project work?
It is a fixed-scope project, with deliverables in writing before we start:
Inventory
Which applications there are, how they are deployed today, which environments you need and what data or provider constraints you have.
Design
Chosen architecture, alternatives ruled out and an approximate infrastructure cost with your provider.
Build as code
Terraform or Ansible for the infrastructure, Helm or the PaaS manifests for the services, all in your repository.
First service
We migrate a real application end to end and use it as a template for the rest.
Handover
Documentation, a session with the team and, if you want, maintenance with the SRE monthly fee.
What experience do we have with platforms?
In CTO roles we have built and maintained the platform of several startups, with container deployments and 99.9% availability. In DevOps at a B2B SaaS company we have worked with multi-cloud environments described as code and CI/CD pipelines that deployed several times a day. What we have learnt: a platform only works if the team understands it and uses it without asking for permission.
Frequently asked questions
Why self-host GitLab instead of using the cloud version?
It usually pays off when the code cannot leave your infrastructure, when cloud CI minutes soar or when you need runners on your own hardware. If none of those reasons applies, we will recommend the cloud service.
Are Coolify or Dokploy fit for production?
Yes, for small teams with a few applications and a couple of servers. Once you have many services, several environments or high availability requirements, Kubernetes or k3s are usually a better option. We will explain where the limit lies in your case.
Who maintains the platform afterwards?
Your team, with the documentation we leave, or us with the SRE as a service monthly fee. The platform does not depend on us: it is in your account and in your repository.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Reviewed on