Straight answers about how GRN.CLOUD actually works.

A Dutch cloud provider running a single Kubernetes-based platform — OpenShift/OKD with KubeVirt — across a distributed mesh of micro-datacentres in the Netherlands. Containers, virtual machines, functions, databases and GPU workloads are all scheduled by the same control plane, against the same network fabric and the same storage. You reach it through a web console, the standard Kubernetes API, Terraform, GitOps or an MCP endpoint.

We operate everything from the hardware up to and including the Kubernetes control plane: hosts, hypervisor, network fabric, storage, cluster upgrades, and the managed services you switch on (databases, backup, monitoring, load balancing). You operate your workloads — your images, manifests, application configuration, data and the access you grant to your people. The Security page sets out the split layer by layer.

No. If you want a virtual machine, you order a virtual machine — KubeVirt runs it and the console gives you a normal VM lifecycle: console access, snapshots, resize, live migration. Kubernetes is the engine underneath, not a prerequisite. If you do know Kubernetes, nothing is hidden from you: it is a conformant API and you get cluster-level control on the dedicated products.

We run a distributed mesh of special-purpose micro-datacentres throughout the country as our cloud regions, and use proven cloud failover techniques — geo-load balancing with BGP-Anycast and BFD for fast failover. Deploying your application redundantly across our regions is your responsibility, and it is free of charge. We provide the tooling to do it easily, and we proactively alert you if we believe you are at risk of losing availability.

Four ways, all against the same API:

• Web console — cluster management, marketplace installs, VM lifecycle, quotas, monitoring dashboards.
• kubectl / oc — the standard Kubernetes CLI against a conformant API.
• Infrastructure as code — Terraform, Helm, or GitOps with Argo CD reconciling the cluster to a Git repository.
• MCP — every GRN.CLOUD app exposes an MCP endpoint, so an AI client can deploy and query resources directly.

Three structural differences rather than three feature differences. Jurisdiction: we are a Dutch company running Dutch hardware, so there is no non-EU parent for a foreign authority to serve. Billing: published per-hour rates with no egress charge and a prepaid wallet, instead of a bill assembled from dozens of metered dimensions. Portability: the stack is upstream open source — Kubernetes, KubeVirt, Ceph, OVN, Prometheus — so leaving is a migration, not a rewrite.

Teams that run production infrastructure and care where it sits: SaaS and software companies, MSPs and hosting partners, public sector and regulated industries (healthcare, finance, legal), and engineering teams leaving VMware or a hyperscaler. If you need a single VM and nothing else, a shared host is cheaper; if you need a platform with policy, isolation and a paper trail, this is built for you.

They differ by how much of the stack is yours alone:

• Public Cloud (SPC) — shared platform, app-level control, tenant isolation by namespace with RBAC, NetworkPolicies and quotas. Best for startups, small sites and dev/test.
• Virtual Private Cloud (VPC) — dedicated compute with shared storage, cluster-level control and kernel isolation. Best for growing businesses, SaaS platforms and production workloads.
• Dedicated Private Cloud (DPC) — fully dedicated hardware, local NVMe, isolated network, hardware-level control. Best for enterprise and regulated industries.

If you need it inside your own datacentre, that is our On-Premise Private Cloud (OPC). Compare them on the pricing page.

CPU, memory and storage can be flexibly allocated according to workload requirements. You pre-buy a bundle of resources and allocate it dynamically to VMs, containers, functions, load balancers or any other resource, and you define standard Kubernetes quotas and limits for auto-scaling and budget-constraining your workloads.

Full hardware and network-level isolation, which gives you maximum security and predictable performance. If you need it in your own datacentre, look at our On-Premise Private Cloud (OPC) product.

One-click deployments of the platform services and applications teams ask for most — managed databases (PostgreSQL, MariaDB, Redis), GitLab, Nextcloud, observability stacks, AI tooling, DevOps tools and VM images. Marketplace apps arrive wired into the platform: SSO, scaling, backup and monitoring are integrated at install time rather than bolted on afterwards.

Yes. PostgreSQL, MariaDB and Redis run as Kubernetes Operators on autopilot: provisioning, failover, minor-version patching, streaming off-site backups and region mirroring are handled by the platform. You get a connection string and a dashboard, not a database server to babysit. See managed databases.

Yes — each is a one-click install from the Marketplace, running in your namespace on your cluster with you as the admin. GitLab brings repos, CI runners and a container registry; Nextcloud brings file sync and OnlyOffice; the AI/ML platform brings model serving, workbenches and GPU scheduling. Any of them can be handed to our engineers as a managed add-on.

Yes. Windows and Linux desktops run as KubeVirt virtual machines on the same platform as everything else, so a desktop pool inherits the same storage, networking, backup and monitoring as your servers. See Virtualisation & VDI.

Yes. We provide instant, full-featured Kubernetes clusters optimised for different use cases such as AI, VDI and AppDev — pick one from the Marketplace with a single click, managed or unmanaged. Backup, monitoring and a web console for self-management come as standard.

Real Kubernetes. We run OKD/OpenShift — upstream Kubernetes with the OpenShift tooling on top — so your manifests, Helm charts, Operators and kubectl muscle memory all work unchanged. Nothing you write for our platform is locked to it.

On a managed cluster our engineers own the control plane, upgrades, patching, backup and monitoring, and you own your workloads. On an unmanaged cluster you take the cluster lifecycle as well — useful if you have a platform team with its own upgrade policy. Both run the same distribution on the same hardware; the difference is who holds the pager.

Yes — we manage patching, upgrades and security fixes with zero downtime.

Yes. Virtual, dedicated (bare-metal) and on-premise private cloud clusters all support manual and automatic scaling through a NodePool in the Cluster Management Console; auto-scaling triggers on a usage threshold you set and stops at a maximum node count you set. Every cloud product, including the public cloud, supports Horizontal and Vertical Pod Autoscaling for containers, and VM auto-scaling through a VirtualMachinePool.

Yes — isolated clusters can be created however you like: per project, per environment or per team. Fine-grained RBAC in the Cluster Management Console lets you assign cluster management per team or per user.

Yes — cluster federation and hybrid orchestration options are available across AWS, Azure, GCP and on-premise.

Yes, hybrid and multi-cloud strategies are supported:

1. Our Cluster Management Console manages external Kubernetes clusters, from lifecycle upgrades to monitoring and backup.
2. We support VPC network peering with Submariner, regular VPN, or direct-connect fibre.
3. With OpenShift storage on both sides you can enable asynchronous storage replication.
4. Streaming data replication through external S3 object storage is supported by the Velero, PostgreSQL, MariaDB and Kafka Operators.

The platform is Kubernetes-based with support for Argo CD GitOps and Helm charts by default. The Marketplace also offers the popular DevOps tools as one-click deployments, with platform integrations — SSO, scaling, backup and monitoring — wired in immediately.

Prometheus for metrics collection, including application health and resource usage; Grafana for visualisation dashboards; AlertManager for alerting; Tempo and OpenTelemetry for tracing. Commercial tools such as Dynatrace and AppDynamics are available through the Red Hat Marketplace.

We are a pure-play Kubernetes provider and do not support other orchestrators as a managed service. You can run other orchestrators yourself on unmanaged VM images that you deploy.

VPS instances are ready within seconds, enabling rapid deployment and scaling. Make sure enough resources are available by topping up your wallet first.

Yes. Resources can be auto-scaled vertically with the VerticalPodAutoscaler and horizontally with the HorizontalPodAutoscaler, both without downtime.

They are scheduled by the same control plane. KubeVirt runs each VM inside a pod on KVM, which means a VM and a container share the same node pool, the same NetworkPolicy enforcement, the same storage classes, the same RBAC and the same audit log. There is no second hypervisor management stack to license, learn or patch. See compute platforms.

Yes — Windows and Linux guests both run on KubeVirt with QEMU/KVM. Licensing for the guest operating system remains yours to hold.

They are live-migrated to another host without downtime. Patching a hypervisor never requires you to schedule a maintenance window for a running VM. OS patching inside an unmanaged VM stays your responsibility; managed VMs are patched nightly through the distribution's package manager.

Yes — a wide range of optimised CPUs, GPUs and storage types can be chosen from the Marketplace, or tailored to your requirements.

Yes. GPU-enabled instances are optimised for AI, ML and HPC workloads, with GPU time starting at €0.03 per hour, and NVMe-oF storage supporting GPUDirect for training data. See the AI/ML platform and the pricing page.

File, block and object storage, all dynamically provisioned to VMs, pods and functions. Block for databases and boot volumes, shared file systems for applications that need RWX, and S3-compatible object storage for artefacts, images and backups. Storage is €0.044 per GB-month and backup €0.008 per GB-month, with no per-GB egress charge on top.

Yes. File, block and object storage can all be dynamically provisioned to VMs, pods and functions. It supports high IOPS, triple redundancy, region replication, compression and encryption. For GPU and AI workloads we have dedicated NVMe-oF storage supporting GPUDirect.

Tiered storage with configurable IOPS, SSD/NVMe options and redundancy. For Dedicated and On-Premise Private Cloud we offer the fastest local NVMe disks, configured either as raw block for maximum performance or as a shared file system for more functionality. For Shared, Virtual and Dedicated Private Cloud we use distributed NVMe-oF disk arrays with redundant 100GE switches optimised for RoCE data transfer. Storage pools are assigned per application profile, so storage is optimised for your use case — raw block for AI and databases, file and object for office and web. IOPS is monitored and we keep at least 40% spare capacity in both storage and network bandwidth.

Automated snapshots, geo-redundant backups and seamless auto-recovery options are available. Velero handles cluster and volume backup; the database Operators stream their own off-site backups.

Yes — persistent volumes and dynamic storage provisioning are available. Our DBaaS products (PostgreSQL, MariaDB, Redis) run on autopilot, streaming off-site backups for auto-recovery and region mirroring.

Storage supports encryption at rest, and traffic into the platform terminates on TLS. Volume-level encryption and compression are configurable per storage pool, and the keys and secrets your application uses stay in your namespace.

In our own Dutch regions by default, geo-redundantly across the micro-datacentre mesh — never shipped to a third-party cloud outside the EU. If you want a copy somewhere else, Velero and the database Operators can stream to any S3-compatible target you nominate.

Built-in firewalls (NetworkPolicies), private subnets (NetworkAttachmentDefinitions) and customisable security groups (RoleBindings) give granular control over every component of the platform, with SELinux and Kyverno policies for runtime security. Our own security monitoring proactively alerts on any deviation.

Within a cloud, tenants are isolated using namespaces. You can define private subnets with network attachments and enforce fine-grained firewalls at the namespace border with NetworkPolicies.

Yes — managed load balancers with auto-scaling and health checks are included by default at no additional cost.

Like any large cloud provider, we use low-latency, high-speed backbone fibre and routing optimised to as many internet exchanges and carriers as possible for near-edge performance. The Netherlands is the most densely fibred country in the world, which helps.

Yes — hybrid deployments are supported over VPN and direct connects. Submariner peers cluster networks so services resolve across sites as if they were local.

No. There is no per-GB charge for traffic leaving our network. Egress pricing is the mechanism that makes leaving a cloud expensive, and we do not think a customer should have to pay a toll to take their own data home. See networking.

Through a managed load balancer with MetalLB and BGP, or an ingress route with TLS certificates issued and renewed by cert-manager. Regional failover uses BGP-Anycast with BFD, so a healthy region takes over quickly when a site drops out.

A fundamental property of cloud-native, containerised environments is that pod restarts can happen at any time — for maintenance, failover or errors — so a true cloud-native workload is architected to withstand them. Our platform is cloud-native, meaning your application is deployed highly available by default with load balancers, storage replication and auto-recovery. That lets us apply maintenance patches when they are needed.

Most managed services (PostgreSQL, MariaDB, VMs, Redis, Nextcloud) are Kubernetes Operators on autopilot and update as soon as upstream patches are released; others ask for confirmation through a notification in the web console. VMs are live-migrated without downtime during hypervisor maintenance. OS patching for unmanaged VMs is the customer's responsibility; managed VM patching runs nightly through the package manager. VM and app images in the Marketplace are rebuilt nightly from upstream, and you can auto-trigger deployment rollouts or CI/CD pipelines on those image changes.

Yes — Pod Security Admission, Kyverno policies and NetworkPolicies are all supported, self-service.

Yes, with audit logging and API key management. RBAC is the same mechanism for containers, VMs, storage and cluster management, so there is one place to reason about who can do what.

Platform engineering staff hold administrative access to the infrastructure — that is unavoidable for anyone who operates hardware — and that access is role-based and logged. We do not read customer workloads or data as a matter of course, and access for support purposes is requested and recorded. Application-level secrets, keys and encryption stay inside your namespace.

The console and Marketplace applications integrate with platform SSO, and applications installed from the Marketplace inherit that integration at install time rather than needing to be wired up afterwards. Bring your own identity provider for your workloads; the platform does not ask you to duplicate your directory.

We are responsible for the physical sites, hosts, hypervisor, network fabric, storage, the Kubernetes control plane and the managed services you enable. You are responsible for your application code and dependencies, your images, your secrets hygiene, the role grants you issue, and your own identity and MFA policy. The Security page states this layer by layer, including where our controls stop.

The platform runs its own security monitoring with SELinux in enforcing mode, Kyverno admission policy and runtime alerting on deviations. You get the alerts that relate to your namespaces. Application-level detection — what your own code does with its own data — remains yours.

In the Netherlands, in our own micro-datacentres, including the backups. Data is not routed through or replicated to jurisdictions outside your control unless you configure that yourself.

No. We are a Dutch company operating Dutch infrastructure, with no US parent or affiliate that could be compelled to hand over data held in Europe. That is the difference between choosing an EU region from a US provider and choosing an EU provider: the first is a configuration setting, the second is a legal structure.

We are GDPR compliant, operate under Dutch and EU law, and sign a Data Processing Agreement as standard. The platform gives you the technical measures auditors ask about: tenant isolation, RBAC with audit logging, encryption, backup with tested restore, and documented data residency.

Yes, a GDPR Data Processing Agreement is available as standard rather than on request. It covers the processing we perform as your processor, the security measures behind it, and the residency commitment. Ask info@grn.cloud for the current version.

We would rather be exact than impressive here: ask us and we will tell you precisely what is certified today, what is in progress, and what is only a roadmap item. We do not list badges we have not earned. What we can state plainly is the jurisdiction, the residency, the DPA and the technical controls above.

Lawful requests are handled under Dutch and EU law, which is the only law we are subject to. A request from outside that framework has no direct route to your data through us, because there is no entity in another jurisdiction in our ownership chain to compel.

Yes. Residency, the processing scope and the sub-processors involved go in the DPA and the contract, not in a marketing page. If your procurement team has a security questionnaire, send it over — we would rather answer it in writing than have you infer the answers.

Three mechanisms, all in the infrastructure rather than in the reporting: 100% renewable generation, peak shaving so we draw least when the grid is most congested, and heat reuse — the thermal output of the servers is captured and delivered to greenhouses and neighbouring buildings instead of the atmosphere.

No. Offsets and certificates are accounting instruments — they do not change what a datacentre does to a grid or to the air above it. We would rather eliminate the impact than purchase the paperwork for it.

Dutch grid congestion is now the binding constraint on where new capacity can be connected — connection queues run for years. Peak shaving means reducing draw from the grid at its busiest moments, using our own generation and storage. It keeps us off congested capacity that other people need, which is why the grid operator is happy to see us connected.

A datacentre's largest physical output is heat. Ours is captured and piped to greenhouses and buildings nearby that would otherwise burn gas for it. The waste output of one process becomes the input of another — which is also why our sites are small and distributed: heat has to be reused near where it is produced.

Talk to us about what you need to evidence and we will tell you what we can support with figures rather than adjectives. We will not hand you a certificate that overstates what we can prove.

Pay-as-you-go at published rates, billed per hour of actual use: vCPU, memory, storage (€0.044/GB-month), backup (€0.008/GB-month) and GPU (from €0.03/hour). A prepaid wallet holds your balance so spend is capped by design. An annual commitment takes 10% off. Virtual Private Cloud and bare-metal clusters add a €99 control-panel fee. Build a configuration on the pricing page.

Yes. Every account starts with a free trial allocation of 1 vCPU and 1 GB of memory, and during the Alpha phase there is additional free capacity to build on — see Alpha access. Namespaced sandbox environments inside your account are always free of charge.

Egress. Managed load balancers. Namespaces and sandbox environments. Per-API-call metering. Support access — you are not charged extra to reach an engineer, and no capability is held back behind a support tier.

Usage analytics, auto-scaling, reserved instances, and cost dashboards with alerts help optimise spend. We work with a prepaid wallet system as a budget allocation, which means you never overspend unexpectedly.

Credit cards, SEPA direct debit and bank wire transfer.

All invoices are available under Account → Billing → Invoices, and are auto-delivered monthly to your registered email. They are EU VAT invoices with sequential numbering per fiscal year.

B2B customers provide a VAT ID during signup or under Account → Billing → Tax Settings, and the reverse charge applies — you declare VAT in your own country. B2C customers pay Dutch VAT at 21%. VIES validation is automatic.

Dutch VAT (21%) for customers who are not VAT-registered. VAT-registered B2B customers get the reverse charge (0% VAT on the invoice). We are OSS/MOSS compliant for EU digital services.

Click "Send me a quote", fill in your requirements, and receive custom pricing within two hours. Quotes are valid for 30 days and convert to an order by replying "Approve" or using the one-click checkout link. Request a quote.

A full refund within 14 days for unused resources — your wallet balance minus what you have consumed. You can cancel at any time under Account → Billing → Close Account. There are no long-term contracts.

24/7 engineering support by ticket (email) and live chat (Slack), plus dedicated SLA support for production that includes monitoring and real-time proactive disaster recovery performed by our engineers, based on your monitoring instructions.

An engineer. We are a small Dutch team and the people who build the platform are the people who answer tickets about it. That is a deliberate constraint on how we scale support, not a temporary state.

Real-time tracing, metrics, logs and alerts through our observability dashboards and APIs — Prometheus, Grafana, AlertManager, Tempo and OpenTelemetry, with your namespaces scoped to you.

Yes, for production workloads on a dedicated SLA support plan, which also covers proactive monitoring and disaster recovery action by our engineers. Ask sales for the current terms that apply to your product and region — we will send the actual document, not a summary of it.

Yes. Marketplace applications and clusters can be handed to our engineers as a managed add-on: installation, version upgrades, backup and restore, and capacity planning. The instance does not change when you switch; only the pager does.

Yes — multi-tenant isolation, per-customer RBAC and per-cluster billing visibility are built into the platform for exactly this. See partners or talk to us.

Create an account and you have a free trial allocation immediately; Alpha access adds free capacity to build something real on. If you would rather scope it with a person first, talk to an engineer and we will size it with you before you spend anything.

Yes. By default you get 1 vCPU and 1 GB of memory free as a trial on account creation. Within an account you can define as many namespaced environments as you need, free of charge — namespaces are sandbox environments isolated by RBAC, NetworkPolicies (firewalls) and resource quotas, which makes them ideal for DTAP.

Depends on the workload:

• VMs — our migration tool connects to your existing VMware, RHV or OpenStack platform and builds seamless migration plans.
• Containers and cloud-native functions — use GitOps to redeploy your Kubernetes manifests.
• Data — Velero backup and restore imports data from other Kubernetes clusters; the Marketplace has ready-made Velero deployment templates.
• Greenfield — start from a one-click Marketplace template.
• Application data — once your app or VM is running, import at the application level.
• Data science — OpenDataHub is our AI platform for building KubeFlow pipelines to import and transform (ETL) data into a data lake.

KubeVirt runs your VMs on KVM under a Kubernetes control plane, and the migration tool builds a plan from your existing vCenter inventory. Most teams move in waves: the least-coupled VMs first, then the ones with storage dependencies, then the network-attached edge cases. You keep running VMs while you decide, workload by workload, which ones are worth containerising. See compute platforms.

A trial environment exists in minutes. A production migration is governed by your data volume and your change windows, not by us — the platform side of a cluster is provisioned the same day. Quotes come back within two hours, so scoping is rarely the bottleneck.

You take your manifests, your images, your VM disks and your data, and you do not pay us for the bandwidth to move them. There is no proprietary API to unwind, because there was never one in the way: upstream Kubernetes, upstream KubeVirt, S3-compatible object storage, standard Velero backups. The best reason to stay is that leaving is easy.