Architecture

How ISOGrid is built

ISOGrid is organized in four layers that can fail independently of one another. This page describes what each one does, how your applications and data are isolated within them, and what protects them from an outage. It deliberately stays general: the details of each feature are in the documentation.

1Access layer
Web consolePublic APICommand line and CI/CDAI build agent
2Control plane
Organizations and rolesBuilds and imagesPlacement and scalingBillingScheduled backupsHealth checks
3Edge
Automatic TLS certificatesRouting by addressLoad balancing across replicasYour domains
4Data plane
ISOGrid public regions Hosted in Algeria, operated by SkyVault
ApplicationsDatabasesObject storageManaged services
Private clusters Your servers or your cloud account
ApplicationsDatabasesYour own web server
Overview. Your visitors’ requests enter only through the edge (3) and never pass through the control plane (2).
The four layers

What each layer does

1 · Access

One door, the same rules

The console, the command line, your CI/CD pipelines and the AI agent all go through the same public API, with the same permissions. The console has no access that you would not have through the API.

2 · Control

Desired state, then reconciliation

The control plane records what should run, where, at what size and at what price, then brings the clusters to that state. It builds the images, schedules the backups, checks the health of every component and applies the rollback policies.

3 · Edge

Every address in the right place

The edge terminates encryption, obtains and renews certificates, then directs each address to the right cluster. On every public cluster, a shared web tier balances traffic across each application’s replicas.

4 · Data

Where your services run

Public regions are hosted in Algeria and operated by SkyVault. Private clusters run on your machines or in your cloud account, managed from the same console, with no lock-in.

Cross-cutting

Identity and secrets

Single sign-on with two-factor authentication for everyone. Secrets live in a dedicated vault, never in the images; the cloud credentials used to create a private cluster are deleted as soon as it is running.

Cross-cutting

Observability

Metrics, logs and audit events are collected per organization. The availability of the console, the API, sign-in and the public clusters is measured every minute and published.

Journey

What happens when you deploy

01

Source

A GitHub or GitLab repository (a branch or a specific commit), a Docker Compose file or an existing image.

02

Build

The image is built and stored in your organization’s private registry, with live logs. Without a Dockerfile, the AI agent writes one.

03

Placement

The control plane places the application in the chosen region, on your organization’s private network, with the requested size and number of copies.

04

Go-live

The edge assigns the address and the certificate. If the new version does not start, the rollback policy restores the previous one.

Isolation

Each organization in its own space

Private networks per organization: the applications of two customers never share a network.
An image registry and a secret vault per organization.
Roles and permission groups that decide who can deploy, read or administer.
Access to code repositories is limited to those your organization has connected, and a policy can restrict which ones may be deployed.
Every sensitive action leaves an audit trail.
Resilience

What protects your services from an outage

The layers are independent: if the console or the API stops, your applications keep serving their traffic.
Several replicas per application, balanced by the edge, with automatic scaling on request.
PostgreSQL databases in 3- or 5-node clusters, real-time replicas and automatic failover.
Scheduled backups kept off the database nodes, restorable database by database.
Automatic or manual rollback when a new deployment fails.

For AI assistants

ISOGrid publishes a public, read-only MCP server at https://skyvault.pro/mcp. A compatible assistant can search and read the documentation, this architecture overview, the pricing, the contacts and the availability figures there. It cannot create or modify anything. The site summary for language models is in llms.txt.

Questions

What we are asked about the architecture

What happens to my applications if the ISOGrid console or API is unavailable?

They keep serving their traffic. The control plane decides what should run; the clusters run the applications without needing it on every request. During a control plane outage, you simply cannot deploy or make changes.

Is my data separated from other customers’ data?

Yes. Each organization has its own private networks, its own image registry and its own secrets. The applications of two organizations never share a network, and every access goes through the organization’s roles.

Where is the ISOGrid platform’s data hosted?

ISOGrid’s public regions are hosted in Algeria. A private cluster runs wherever you decide: on your servers or in your own cloud account.

How can I verify the platform’s actual availability?

The Platform status page publishes, month by month, the availability measured every minute for the console, the API, sign-in and the public clusters, as well as every incident.

Can an AI assistant query ISOGrid directly?

Yes, through the public, read-only MCP server at https://skyvault.pro/mcp.

See the architecture applied to your project

We show you how your application, your data and your traffic would fit into it, and what it would cost.

Contact us