Microsoft Azure

Reads your Azure estate so apps can point at real infrastructure.

Capability: hosting · Hosting. This is a generic capability: every enabled instance receives the same one-way pushes, so several can be connected side by side.

Vendor site · Vendor docs

Configure Microsoft Azure in Atrium → (admins only)

Setup

Atrium reads resource groups and services from your Azure subscription so an app environment can name where it really runs. Create a service principal, give it Reader on the subscription, and paste its four values.

Register an application. Entra ID → App registrations → New registration. Single tenant is fine; no redirect URI is needed — this is a daemon credential. Open the console page ↗
Copy the tenant + client ids. From the app’s Overview blade: Directory (tenant) ID and Application (client) ID.
Create a client secret. Certificates & secrets → New client secret. Copy the VALUE (not the Secret ID) immediately — Azure never shows it again.
Grant Reader on the subscription. Subscriptions → your subscription → Access control (IAM) → Add role assignment → Reader → assign to the app registration. Reader is enough; do not grant Contributor unless you intend Atrium to write.

What you paste back into Atrium

In order, the values the steps above produce:

Tenant ID
Client ID
Client secret
Subscription ID

How it works

A read-only window onto your Azure estate, so an app environment can name the infrastructure it actually runs on instead of carrying a string someone typed. Atrium authenticates as a service principal (client credentials, no signed-in user) against the Azure Resource Manager API. Be aware of the current limit below before connecting.

What Atrium does, and when

When this happens	Atrium does this
An app environment is pointed at Azure	Reads resource groups and services under the configured subscription so the target can be selected rather than typed.
Any read	Mints a token for the configured tenant with the client id and secret, scoped to Azure Resource Manager. Optionally narrowed to one resource group when that field is set.

Guarantees and limits

Reader on the subscription is the documented and sufficient role. Contributor would let Atrium write, which nothing here does; granting it is over-permissioning.
Read-only by construction: the connector issues no write calls, so a mistake here cannot change your Azure estate.
Current limit, worth knowing before you connect: the hosting resolver only builds a client for Dokploy. An enabled Azure instance is stored and testable, but the hosting capability does not yet resolve to it, so seat management and ingress-IP lookup still come from Dokploy.
Hosting is a generic capability: every enabled instance receives the push, so Azure and Dokploy can both be connected.
The client secret is encrypted at rest (AES-256-GCM) and never returned to the browser.

What "Test connection" proves

Mints a service-principal token and performs one read against the subscription. A pass proves all four values are correct and the Reader assignment took effect.

Troubleshooting

Symptom	Cause	Fix
Authentication fails with an invalid-client-secret error.	The Secret ID was pasted instead of the secret VALUE. Azure shows both and only the value works.	Create a new client secret and copy the Value column immediately; it is never shown again.
Authentication succeeds, the subscription read returns nothing.	The Reader role assignment was never made, or was made on a resource group rather than the subscription.	Subscriptions → the subscription → Access control (IAM) → confirm the app registration holds Reader at subscription scope.
It stops working after roughly a year.	The client secret expired.	Issue a new secret and paste it. Diarise the next expiry when you create it.

Required scopes

Grant the credential exactly these scopes; they are the least-privilege set the connector needs:

Service principal with the Reader role on the target subscription (Contributor only if you later want Atrium to write)

Configuration fields

Field	Type	Required	Notes
`tenantId` Tenant ID	`text`	yes	e.g. `00000000-0000-0000-0000-000000000000`
`subscriptionId` Subscription ID	`text`	yes	e.g. `00000000-0000-0000-0000-000000000000`
`clientId` Client ID	`text`	yes	e.g. `00000000-0000-0000-0000-000000000000`
`clientSecret` Client secret	`password` secret	yes	The secret VALUE from Certificates & secrets, not the Secret ID. e.g. `…`
`resourceGroup` Default resource group	`text`	no	Optional. Narrows reads to one group instead of the whole subscription. e.g. `rg-atrium-prod`

Operating notes

Secret fields are encrypted at rest (AES-256-GCM) and never returned to the client. Editing an instance and leaving a secret field masked keeps the stored value.
Adding a connector from the marketplace creates a disabled, credential-less instance ("Added, not yet connected"); it does nothing until an admin opens it, pastes credentials, and enables it.
Use Test connection on the instance page before enabling: it performs a read-only probe with the credentials you entered.
Connector credentials live in the Atrium database, not in container env vars; changing them here takes effect without a redeploy (within the resolver's 30-second cache).