For the complete documentation index, see llms.txt. This page is also available as Markdown.

Deployment

How an akenza Enterprise deployment is hosted: the deployment models, multi-region setups, and domains.

An akenza Enterprise deployment is a tenant of its own. The platform runs either in an akenza cloud subscription or in a customer cloud subscription, using several infrastructure components to process and manage IoT data at scale.

Cloud platforms

akenza deploys on any of the major cloud providers:

  • Amazon Web Services (AWS)

  • Google Cloud Platform (GCP)

  • Microsoft Azure

On-premises deployment is available on request only. If your requirements rule out public cloud, raise it early, because it shapes the rest of the arrangement.

Picking the provider you already use keeps the deployment inside the cloud governance, billing, and network your organization has established, which matters most in the customer subscription model below.

Deployment models

Which model applies decides who holds the cloud subscription, who has access to the infrastructure, and where responsibility sits when something needs changing.

Model
Who operates it
Infrastructure access

Enterprise SaaS

akenza operates the private cloud deployment in its own cloud subscription.

No infrastructure access for customers.

Customer subscription

akenza deploys and operates the private cloud deployment in the cloud subscription of the customer.

akenza has full access to deploy infrastructure components and applications.

Shared responsibility

A hybrid mode: the customer's DevOps team manages the infrastructure, and akenza manages the application deployed on top of it.

Split between both parties.

Enterprise SaaS

The simplest of the three. akenza holds the subscription, runs the deployment, and customers work only with the platform itself. Choose it when a private deployment is wanted without taking on any infrastructure of your own.

Customer subscription

The deployment lives in your own cloud subscription, so the infrastructure and the data on it sit within your organization's cloud governance, while akenza still deploys and operates it.

akenza needs credentials with enough rights to deploy and maintain the infrastructure components and the application.

Shared responsibility

Your DevOps team owns the infrastructure and akenza owns the application running on it. This suits organizations with an established cloud practice that expect to manage infrastructure themselves.

Multi-region setup

Latency between devices and the platform is a real constraint, so a deployment should be placed in the region it serves. Where worldwide coverage is needed, akenza is deployed once per geographical region, for example in EMEA, APAC, and the US.

Plan for this at the outset. Deciding which region a customer, site, or fleet belongs to is straightforward before onboarding and awkward afterwards, because moving devices between deployments means recreating them.

Domains and certificates

A deployment is reached either under an akenza domain or under your own:

Option
What it requires

akenza domain

Nothing. The deployment is hosted under *.<customer>.akenza.io.

Custom domain

A wildcard certificate covering all akenza hostnames, and DNS records configured accordingly.

A custom domain is what makes a deployment feel like your own product rather than akenza's, and it pairs with white labeling, which changes the name, colors, and logo inside the application.

The certificate has to cover every akenza hostname on the deployment, not just the main one. Certificate renewal stays your responsibility for the life of the deployment, so it is worth putting the expiry in the same calendar as your other certificates.

Getting a deployment

Deployment models, regions, and domains are agreed as part of an Enterprise arrangement. To discuss which model fits, get in touch through the Service Desk.

Last updated

Was this helpful?