A container platform you can use at first login
Most of the time lost on a Kubernetes project goes into groundwork: installing the runtime, choosing an ingress, wiring certificates, finding out why the dashboards are empty. On 4hosting that groundwork is done before you connect. Log in over SSH to a VPS or a dedicated server and you find Docker, Compose, a single-node k3s cluster, kubectl and helm in place, with ingress, certificate issuing and monitoring already wired together. The servers stand in Frankfurt, support answers in English and Romanian, and the DevOps hours that come with your plan can be spent on the cluster itself: an architecture review, the first deployment, upgrades and a cost check.
What is waiting after your first SSH login
Docker Engine and Compose
Docker Engine, Compose v2 and BuildKit let you build images on the server, and a local registry keeps them close to where they run. Container logs flow to Loki and metrics to Prometheus without extra setup.
k3s, a lightweight Kubernetes
k3s is a conformant Kubernetes distribution shipped as one small binary, so you work against the standard API. A single node is enough to start, more nodes can join later, and a 2 GB VPS runs a small cluster. Production workloads deserve more memory than that.
kubectl, helm and kustomize
The command-line tools you would install first are already on the path. Helm 3 and kustomize both work, and cert-manager is ready to issue TLS certificates for anything you expose.
A private image registry
A private Harbor registry keeps your images on your own server. GitHub Actions, GitLab CI or Jenkins can push to it, and image scanning reports known CVEs before a build reaches production.
Ingress with Traefik
Traefik routes outside traffic into the cluster and requests Let's Encrypt certificates on its own. Wildcard certificates, HTTP/3 and custom middleware are supported, so a new hostname costs you one manifest.
Metrics, logs and alerts
Prometheus gathers CPU, memory, network and disk figures, Grafana draws them and Loki stores the logs. Starter alerts go to Slack or e-mail, and you adjust thresholds to the service levels you promise your own customers.
Network policy and secrets
Cilium provides the pod network with NetworkPolicy support, and Vault is available for secrets, so passwords and API keys stay out of your manifests and your Git history.
From a fresh VPS to a running app in five steps
Connect over SSH to a new VPS and run these commands in order. They are ordinary kubectl and helm calls, so whatever you learn here carries over to any other Kubernetes cluster you meet later.
Check that the cluster is up
kubectl get nodesOne node in the Ready state means k3s is running. If you log in seconds after the first boot and see an error, the cluster is still starting; try again shortly.
Install your application with helm
helm install web ./charts/web --namespace shop --create-namespaceUse your own chart or any public one. Helm creates the deployment, service, ingress and volume claims it describes, all inside a namespace of their own.
Point a domain and get TLS
kubectl -n shop apply -f ingress.yamlAnnotate the ingress for cert-manager and create an A record that points to the server's IP address. Traefik serves the site and a Let's Encrypt certificate is issued without further steps.
Scale out when traffic grows
kubectl -n shop scale deployment web --replicas=5Five replicas of the same app sit behind the ingress and Traefik spreads requests between them. For load-based scaling, add a HorizontalPodAutoscaler instead of a fixed number.
Roll back a bad release
kubectl -n shop rollout undo deployment/webKubernetes keeps the previous ReplicaSet, so reverting a faulty version is one command and does not need a new build.
One VPS with Docker, k3s on a VPS, or managed Kubernetes?
Match the platform to the size of the problem. One application with a database often runs best on a single VPS with Docker Compose. Once you have several services, separate environments or more than one team, k3s on a VPS or a dedicated server gives you Kubernetes without a cloud bill that grows with every component. The managed Kubernetes of a large cloud starts to pay off when you need many nodes across regions.
| Criterion | VPS with Docker | k3s on VPS or dedicated | Managed Kubernetes at a large cloud |
|---|---|---|---|
| Effort to start | A few minutes with a Compose file | Already installed; you apply manifests | Account, networking and access roles to configure first |
| Scaling | Manual: add containers or resize the VPS | HPA and VPA; add nodes by joining another server | HPA, VPA and a cluster autoscaler |
| Isolation between workloads | Limited to what Docker offers | Namespaces, quotas and NetworkPolicy | The same, plus cloud-level identity and network controls |
| Cost model | The server you rent | The server you rent, nothing per pod | Typically a control-plane fee, plus nodes and outgoing traffic |
| Who runs it | You manage the host and the containers | You, with included DevOps hours for upgrades and reviews | The provider runs the control plane, you run the rest |
| Best fit | One application and a small team | Several services, staging and production, agencies | Large fleets, many nodes, multi-region |
How teams in Romania use it
Microservices for a payments or logistics platform
Picture a fintech team in Bucharest breaking a monolith into a few dozen services. Each runs as its own deployment with resource limits, internal traffic is encrypted with mTLS through Cilium or Linkerd, and releases go out blue-green so one faulty build never reaches every user.
CI/CD that ends in a rollout
GitHub Actions or GitLab CI builds the image, pushes it to the registry and triggers a rollout. Nobody deploys from a laptop. If a release misbehaves, one kubectl rollout undo command puts the previous version back.
A software house hosting many client projects
An agency in Cluj-Napoca gives each customer a namespace with CPU and memory quotas, plus a NetworkPolicy that stops one tenant from seeing another. A single dedicated server can hold a long list of small workloads.
Dev, staging and production side by side
An IT outsourcing team in Timisoara runs three environments on one dedicated server with identical configuration. A manifest proven in staging goes to production with a single kubectl apply.
Campaign peaks in e-commerce
An online shop that expects a Black Friday spike raises its replica count, or lets a HorizontalPodAutoscaler do it, and scales back when the rush ends. You pay for the server you rent, not for each extra replica.
Foreign-owned teams with EU data rules
A Romanian subsidiary of a multinational that must keep workloads inside the EU runs its containers in Frankfurt, signs a data processing agreement under GDPR Article 28 and receives invoices with Romanian VAT shown separately.
Moving containers over from another platform
Migration is free, and we carry it out with you whether the workload is a Compose file, a Heroku-style app or a cluster in another cloud. The sticking points are nearly always the same: persistent volumes, environment variables and the DNS cut-over. We plan for those first and leave the easy parts for last.
The DevOps toolbox that comes with it
Docker and Kubernetes questions we hear most
Is k3s suitable for production?
Yes. k3s is a CNCF-conformant Kubernetes distribution, created by Rancher (now part of SUSE) and widely used in production. It stays light by dropping optional and legacy components, while the API your tools talk to is the standard Kubernetes API.
What if one node is not enough?
Order a second VPS or dedicated server and join it to the cluster with the join token and one command. For a control plane that survives the loss of a machine, run three server nodes. We can set that up for you, and Longhorn replicates volumes between the nodes.
Can I spend the included DevOps hours on my cluster?
Yes. Plans include 1 h/month from cPanel Advanced up, 1–8 h on VPS, 5–10 h on dedicated servers depending on plan, and 10 h on GPU servers. You request the hours from the client panel, you propose a date, and our team delivers. Hours are not carried over to the next month, and extra hours are accepted and billed separately.
Can I use Docker Swarm instead of Kubernetes?
You can, and it still runs. But most tooling, Helm charts and hiring pools have moved to Kubernetes, so a new project built on Swarm tends to cost more to maintain later. k3s keeps the learning curve gentle while staying on the standard.
How are Kubernetes resources billed?
By the server you rent, not by pods or containers. You can run a handful of pods or a hundred on the same VPS and the plan stays the same; the limit is the CPU, memory and NVMe disk you have. Current plans are listed on the pricing page.
Where does the cluster run and who can reach the data?
On servers in Frankfurt, inside the EU. We sign a data processing agreement under GDPR Article 28 and use standard contractual clauses for any transfer outside the EU. Our security controls are aligned with ISO 27001, which is alignment and not a certificate.
Start with a VPS and the cluster is already there
Choose a VPS with NVMe storage on the plans page, log in over SSH and run your first kubectl apply. If you are arriving from another platform, our free migration moves manifests and data with you. Current plans and prices are on the pricing page.
See VPS plans →