> For the complete documentation index, see [llms.txt](https://docs.akenza.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akenza.io/general/tenants/deployment.md).

# Deployment

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

An akenza Enterprise deployment is a [tenant](/general/tenants.md) 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**

{% hint style="info" %}
**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.
{% endhint %}

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.

<table><thead><tr><th width="200">Model</th><th>Who operates it</th><th>Infrastructure access</th></tr></thead><tbody><tr><td><strong>Enterprise SaaS</strong></td><td>akenza operates the private cloud deployment in its own cloud subscription.</td><td>No infrastructure access for customers.</td></tr><tr><td><strong>Customer subscription</strong></td><td>akenza deploys and operates the private cloud deployment in the cloud subscription of the customer.</td><td>akenza has full access to deploy infrastructure components and applications.</td></tr><tr><td><strong>Shared responsibility</strong></td><td>A hybrid mode: the customer's DevOps team manages the infrastructure, and akenza manages the application deployed on top of it.</td><td>Split between both parties.</td></tr></tbody></table>

### 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.

{% hint style="info" %}
akenza needs credentials with enough rights to deploy and maintain the infrastructure components and the application.
{% endhint %}

### 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.

{% hint style="warning" %}
Because the responsibility boundary runs through the middle of the system, this model requires close collaboration and a **custom service level agreement with its own service level objectives**. Agree both before committing to it, since the standard terms do not describe this split.
{% endhint %}

## 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.

{% hint style="warning" %}
Regional deployments are **not synchronized**. Each is a separate tenant, managed separately, with its own organizations, users, devices, and tenant-level configuration. Something set up in one region has to be set up again in the others.
{% endhint %}

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:

<table><thead><tr><th width="220">Option</th><th>What it requires</th></tr></thead><tbody><tr><td><strong>akenza domain</strong></td><td>Nothing. The deployment is hosted under <code>*.&#x3C;customer>.akenza.io</code>.</td></tr><tr><td><strong>Custom domain</strong></td><td>A <strong>wildcard certificate</strong> covering all akenza hostnames, and <strong>DNS records</strong> configured accordingly.</td></tr></tbody></table>

A custom domain is what makes a deployment feel like your own product rather than akenza's, and it pairs with [white labeling](/device-management/managing-an-organization/general-settings/white-labeling.md), which changes the name, colors, and logo inside the application.

{% hint style="info" %}
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.
{% endhint %}

## 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](/faq/service-desk.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.akenza.io/general/tenants/deployment.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.