Hosting and deployment

Shared, dedicated, or on the customer's own hosting — account by account.

In detail

Each account chooses its hosting model, and both models coexist in the same console. The trade-off between cost and sovereignty is made account by account, and even fleet by fleet: an account can mix the two.

The two models

Creating a dedicated zone

A dedicated zone is created from the console, inside the customer's cloud subscription, with no intervention from Arkipelis: a few minutes between consent and the first deployment.

The account administrator designates their subscription and grants consent. The foundation is then laid on their side — resource group, identity, image registry, storage, vault, execution environment and reconciliation component. They then deploy Fleet or Octopoda onto that zone in one click.

Nothing passes through Arkipelis: their data, their images and their secrets are born inside their subscription. A dedicated zone sees no identifier from the central database, and no real-time traffic passes through the vendor.

What the zone serves

Devices only talk to their zone's plane, which serves heartbeats from its own cache and forwards only rare operations to the central plane. A deployment computed in the zone is identical to the central computation; only the location changes.

The zone is also the first level of the configuration cascade: image defaults, fallback WiFi networks, firewall, scripts and default network are set there, then inherited by the account, the fleet and the device.

Several hosting providers

The architecture is not tied to one provider: it rests on standard building blocks. A reference implementation serves as the base, and modular provisioning carries zones to other providers to meet a customer's sovereignty or cloud preference requirements. The same deployment model applies — only the equivalent managed services change.

Isolated environments

Production, qualification and development are complete and independent platforms: each has its own databases, interfaces, consoles and cloud resources, with no shared resource at all. A change is validated end to end in qualification before reaching production, and an incident on one environment cannot affect another.

Cost follows activity

On the Octopoda side, each account has its own database. It pauses automatically for a dormant account and moves to a provisioned tier for an active one — in both directions. Onboarding a new customer is measured in minutes, and their hosting cost follows their actual activity.

Compliance and reversibility

• Enterprise sign-in: users come in with their usual identity.
• Their profile is created on first access, with no intervention.
• Disabling an account in the directory is enough to cut off all access.
• Tamper-proof traceability: deployments, card writes, hardware changes and maintenance are recorded.
• These logs can be neither modified nor deleted, even by an administrator.
• And even after the repository's history has been rewritten.
• Teams and scopes: two levels, administration and read.
• What is outside your scope does not appear.
• Technical credentials follow the same teams automatically.
• Reversibility: the business code belongs to the customer, their data is with them. Leaving remains possible.

Offers and facets

The platform is organised into offers: the fleet management foundation, the Data suite, the Distrib suite, and the payment option. Facets ship disabled by default and are enabled according to the account's licence. This is enforced platform-side: an account cannot enable a capability it has not subscribed to, and the pages, tabs and widgets of an unsubscribed facet are simply absent.