Private clusters without lock-in

What runs on your machines is standard Docker Swarm or Kubernetes, and it keeps running if you leave.

A private cluster is a cluster only your organization uses. It runs on your own machines added over SSH, on machines we build in your own cloud account, or on machines an Algerian provider sets up for you. ISOGrid operates it, but nothing about it only works with ISOGrid. You can stop using ISOGrid, and your applications keep running on the same machines.

What the cluster is made of

Everything on the machines is standard software you could have installed yourself:

  • Docker Engine and Docker Swarm, or k3s, a certified Kubernetes distribution. The console calls Swarm "serverless container apps", but it is still plain Swarm, and docker service ls or kubectl get pods show the same services the console shows.
  • Ordinary container images. Every build is pushed as a standard OCI image to your organization's own project in the registry. Any registry and any runtime can use it.
  • Plain NGINX at the edge, running as an ordinary Swarm service. If you brought your own NGINX or Traefik, it stays yours.
  • Databases in their usual formats. PostgreSQL, MySQL and MongoDB export with their own standard tools.

The platform uses no private runtime, custom orchestrator or proprietary image format. The machines run your applications without ISOGrid's help: we only update the cluster when you change something in the console.

What we keep, and what we delete

  • Cloud credentials are used once to build the cluster in your account, then deleted as soon as it is running. We keep no standing access to your cloud account, and the machines, disks and networks are billed to you by the provider.
  • An OpenShift admin token is used once to install our access, then deleted.
  • The password of a machine you add over SSH is used once to install our own SSH key, then deleted.

In every case the machines belong to you. Removing a machine or a cluster in the console deletes our records of it and leaves the machine as it is.

The one exception is machines ISOGrid orders in its own accounts (Contabo, Hetzner, OVHcloud). Those machines are ours and removing the cluster destroys them. If you want to keep your machines when you leave, choose your own account at the same provider instead.

Leaving, step by step

  1. Copy your images. Sign in to the registry with docker login, using a login credential from the Images page, then pull your images and push them to a registry of your own. Your running services still point at ISOGrid's registry, so update them to the new address before you leave.
  2. Export your databases with pg_dump, mysqldump or mongodump, or download a backup from the database page.
  3. Remove the cluster from Integrations.
    • For your own machines, the cluster keeps running after removal.
    • For a running cluster we built in your cloud account, open a ticket and we will detach it. We no longer hold your credentials, so we cannot delete anything in your account. Everything we created is labelled isogrid-cluster, which makes it easy to find.
  4. Remove our access from the machines:
    • Delete the line ending in isogrid from ~/.ssh/authorized_keys.
    • On Kubernetes and OpenShift, run kubectl delete clusterrolebinding isogrid-controller and kubectl delete namespace isogrid-system.
    • Keep the isogrid-web NGINX service if you still want it, or remove it with docker service rm isogrid-web.

There is no departure fee, and you do not need to ask us for permission to leave. See also Data you can take with you.