Install guide

Installing MikeOSS on your Azure tenant

The minimal, hand-rolled deployment. Around an hour, end to end.

This guide walks an Azure professional through the minimal hand-rolled install of MikeOSS into their own tenant. You will need access to the Azure portal and a Postgres-capable region. For a supported, one-click install please see the Azure Marketplace listing; this guide is for people who want to understand every resource.

Goal of step 1: one container that holds every other Azure resource we are about to create. Deleting that resource group at the end deletes everything we deployed in a single click. That is handy for cleanup.

Click any screenshot to view it at full size. Where the screen was too tall for a single capture, you will see two or three panels stacked together; they are all part of the same view.

{/* ============================ STEP 1 ============================ */}

Create the resource group

The resource group is where you decide the residency for your data. That is essential if you are a UK or EU organisation, so pick the location that suits you.

1.1 Sign in to the portal

Open portal.azure.com and sign in.

1.2 Find Resource groups

In the top search bar, type resource groups and click the Resource groups service result (the one with the cube-stack icon, under Services).

1.3 Click Create

On the Resource groups list page, click + Create in the top toolbar.

1.4 Fill in the Basics tab

Subscription: pick the subscription you want to bill this to.
Resource group: rg-mike-mini (substitute your own suffix if you prefer).
Region: (Europe) UK South.

The region you pick needs to support Postgres Flexible Server, Container Apps and Azure OpenAI if you ever extend the deployment. UK South does. So do most major regions (North Europe, East US, and so on). Pick one and stick with it for every resource in this guide.

Skip the Tags tab, click Review + create, then Create when validation passes.

1.5 Wait for deployment

Wait for the “Your deployment is complete” banner (usually under 10 seconds) and click Go to resource group. You will land on the empty overview page for rg-mike-mini.

You should be looking at the overview page for rg-mike-mini, in your chosen region, with zero resources inside it. {/* ============================ STEP 2 ============================ */}

Create the Log Analytics workspace

Container Apps need somewhere to send their logs. The cheapest and simplest option is a basic Log Analytics workspace, which we will create first. We will then create the Container Apps Environment (the runtime that hosts the actual container) and point it at this workspace. Both resources are free at the volumes a single small app produces; you only start paying once you cross the free ingestion tier (5 GB per month at the time of writing).

2.1 Find Log Analytics workspaces

In the top search bar, type log analytics and click the Log Analytics workspaces result.

2.2 Click Create

Click Create in the top toolbar.

2.3 Fill in the Basics tab

Subscription: same as before.
Resource group: rg-mike-mini.
Name: law-mike-mini.
Region: UK South (use the same region as your resource group).

2.4 Skip the optional tabs

Skip the Pricing tier tab. The default Pay-as-you-go tier with the free 5 GB included is fine for a minimal deployment. Skip Tags. Click Review and create, then Create.

2.5 Wait, then open the workspace

Wait for the deployment to complete (around 20 seconds) and click Go to resource. You will land on the workspace overview page.

Inside rg-mike-mini you should now see one resource: law-mike-mini. {/* ============================ STEP 3 ============================ */}

Create the Postgres Flexible Server

Mike stores its application data in Postgres. We will use a Flexible Server on the Burstable tier, which is the cheapest configuration that runs a real workload.

3.1 Open the Marketplace

From the rg-mike-mini overview page, click Create in the top toolbar. This opens the Marketplace.

3.2 Find the right tile

In the Marketplace search box, type postgresql flexible and click the Azure Database for PostgreSQL Flexible Server tile. The publisher is Microsoft.

There is also a tile for “Azure Cosmos DB for PostgreSQL”, which is a different product. Do not pick that one.

3.3 Pick the Flexible server deployment option

On the tile, click Create. The next page asks you to pick a deployment option. Click Create on the “Flexible server” card. There are usually three cards: Flexible server, Single server (deprecated), and Cosmos DB for PostgreSQL. We want Flexible server.

3.4 Fill in the Basics tab

Subscription: same as before.
Resource group: rg-mike-mini.
Server name: pg-mike-mini.
Region: UK South.
PostgreSQL version: 16.
Workload type: Development.

Pick Development even if you plan to take the deployment to production later. It sets sane defaults; the Production preset overprovisions and costs a lot more.

Compute and storage: click Configure server. On the Configure blade, pick the Burstable tier, B1ms compute size, 32 GiB storage, 7 days backup retention. Click Save to return to the Basics tab. You should see the monthly price drop from around £400 to roughly £13.

Availability zone: No preference.
High availability: leave unchecked. Burstable does not support zone-redundant HA anyway, and we are deliberately not paying for it in a minimal deploy.
Authentication method: PostgreSQL authentication only. Do not pick “Microsoft Entra authentication only” or “PostgreSQL and Microsoft Entra authentication”. The minimal deployment uses password auth; switching to Entra auth is a separate exercise covered in the production-hardening notes.
Admin username: mikeadmin.
Password: generate a strong one and save it now. You will need it three times: for the schema migration in step 7, for the application connection string in step 8, and any time you debug Postgres directly.

Use a password manager. There is no Key Vault holding it for you in this deployment.

3.5 Networking tab

Click Next to go to the Networking tab. This is where the firewall rules go.

Connectivity method: Public access (allowed IP addresses). Do not pick Private access (VNet integration); that is the production hardening path.
Tick Allow public access to this resource through the internet using a public IP address.
Tick Allow public access from any Azure service within Azure to this server. This is what lets the Container App reach Postgres later.
Under Firewall rules, click Add current client IP address. This adds a single rule with your laptop’s public IP, which is what we will use to run schema migrations from local in step 7. The portal shows you the IP it detected.

3.6 Skip Security and Tags

Click Next twice to skip Security and Tags (defaults are fine). On Review and create, wait for validation to pass and click Create.

3.7 Wait for provisioning

This takes around 5 to 8 minutes. While you wait, you can read ahead to step 4 (storage account), but do not start clicking yet. We have one more thing to do on Postgres before moving on.

3.8 Capture the FQDN

When the deployment finishes, click Go to resource. You will land on the server overview page. Capture the value of Server name at the top right of the Essentials panel. It will be in the form pg-mike-mini.postgres.database.azure.com. That is the FQDN we need in steps 7 and 8.

3.9 Allow-list the required Postgres extensions

In the left navigation, scroll down to the Settings section and click Server parameters. The page lists hundreds of parameters; in the search box at the top type azure.extensions.

Click into the row, change the value to include both PGCRYPTO and VECTOR (you can multi-select from the dropdown), and click Save at the top of the page. The portal will warn that the change requires a restart and offer to restart the server now. Click Save and Restart.

This step matters. Without it, the schema migrations in step 7 fail when they hit CREATE EXTENSION pgcrypto.

3.10 Wait for the restart

The restart takes 1 to 2 minutes. The server overview moves from a yellow “Updating” status to a green “Available” status when it is ready.

In your notes outside Azure:

The admin password, somewhere safe (and admin name if you used a different one).
The FQDN pg-mike-mini.postgres.database.azure.com.

In the portal, rg-mike-mini should now contain law-mike-mini, pg-mike-mini, and the Postgres server’s deployment artefacts. The Postgres server’s status should be Available.

{/* ============================ STEP 4 ============================ */}

Create the storage account and the documents container

This is the simplest of the resource-creation steps. Two clicky bits: the storage account itself, then a single blob container inside it. Plus capturing the connection string at the end.

4.1 Open the Marketplace

From the rg-mike-mini overview page, click Create in the top toolbar. In the Marketplace search, type storage account and click the Storage account tile. The publisher is Microsoft. Click Create on the tile.

4.2 Fill in the Basics tab

Subscription: same as before.
Resource group: rg-mike-mini.
Storage account name: stmikemini.
Region: UK South.
Primary service: leave on the default “Azure Blob Storage or Azure Data Lake Storage Gen 2”.
Performance: Standard.
Redundancy: Locally-redundant storage (LRS). The other redundancy options are nice-to-haves we do not need for a minimal deployment and they cost more.

4.3 Advanced and Networking tabs

Click Next through Advanced (defaults are fine) and Networking (default: Enable public access from all networks). We will lock the network path down later as part of production hardening.

4.4 Data protection, Encryption, Tags

Click Next through Data protection, Encryption, and Tags. Defaults are fine throughout.

4.5 Security tab: two things to verify

Require secure transfer for REST API operations: ticked. This forces HTTPS.
Allow enabling anonymous access on individual containers: unticked. We want all blobs auth-gated.
Minimum TLS version: Version 1.2. This is the default on new accounts but check the dropdown.

Leave the rest of the tab on defaults: hierarchical namespace off, SFTP off, NFS v3 off, large file shares disabled.

4.6 Review and create

On Review and create, wait for validation to pass and click Create. Provisioning takes 30 to 60 seconds.

4.7 Open the resource

When deployment finishes, click Go to resource. You will land on the storage account overview page.

4.8 Create the documents container

In the left navigation, expand Data storage and click Containers. The Containers page has a + Container button at the top. Click it.

4.9 Name it and set access

In the side blade, set Name to documents (lowercase, no spaces). Set Anonymous access level to Private (no anonymous access). Click Create.

4.10 Confirm the container exists

4.11 Capture the connection string

We need this for step 8 to wire the application up to blob storage. In the left navigation under Security + networking, click Access keys. Click the Show button next to key1. Copy the entire Connection string value (the one that starts with DefaultEndpointsProtocol=https;AccountName=...). Save it somewhere safe; you will paste it into the Container App secrets in step 8.

rg-mike-mini should now contain law-mike-mini, pg-mike-mini, stmikemini, plus any Postgres deployment artefacts. In your notes you should have the Postgres admin password and FQDN from step 3, and the storage connection string from step 4. {/* ============================ STEP 5 ============================ */}

Create the container registry

The container registry (ACR) is where the application image lives. The Container App pulls from here on every cold start. We use the Basic SKU with the admin user enabled, which is the cheapest and simplest option for a manual deployment. The production-grade alternative is to attach a Managed Identity with the AcrPull role, but that is part of the production-hardening track.

5.1 Open the Marketplace tile

From the rg-mike-mini overview page, click Create in the top toolbar. In the Marketplace search, type container registry and click the Container Registry tile. The publisher is Microsoft. Click Create on the tile.

5.2 Fill in the Basics tab

Subscription: same as before.
Resource group: rg-mike-mini.
Registry name: acrmikemini. This name must be globally unique across all of Azure, so if validation later fails with “name not available”, append two or three random characters and use that everywhere from this step onwards.
Location: UK South.
Pricing plan: Basic.

5.3 Skip Networking, Encryption, Identity, Tags

Click Next through Networking (default: Public access enabled), Encryption, Identity and Tags. Defaults are fine.

5.4 Review and create

Wait for validation to pass and click Create. Provisioning takes around 30 seconds.

5.5 Capture the Login server

When deployment finishes, click Go to resource. Capture the Login server value from the Essentials panel. It will be acrmikemini.azurecr.io. We will use that in steps 6 and 8.

5.6 Enable the admin user

In the left navigation, scroll to the Settings section and click Access keys. The page shows the Admin user toggle, set to Disabled by default. Click it to Enabled. The page refreshes and shows the username and two passwords (password, password2).

5.7 Capture the credentials

Username is the registry name (acrmikemini). Click the show button next to password and copy the value. Save the username and password somewhere safe; we paste them into the Container App pull-credentials field in step 8. There is a password2 too; that is the standby key for rotation. Ignore it for now.

rg-mike-mini should now contain law-mike-mini, pg-mike-mini, stmikemini, acrmikemini and assorted deployment artefacts. In your notes: Postgres admin password and FQDN, storage connection string, ACR login server (acrmikemini.azurecr.io), ACR admin username (acrmikemini) and password. {/* ============================ STEP 6 ============================ */}

Build the application image

This is the first of two steps that cannot be done from the portal blades alone. We use Azure Cloud Shell, the bash terminal embedded in the portal. No local Docker or az CLI install is needed, and Cloud Shell is already authenticated as your portal user.

The build itself runs on Azure’s side via ACR Tasks. Cloud Shell is just where we type the command from. The first build of this image takes around 5 to 10 minutes because the multistage Dockerfile installs LibreOffice (used for DOC and DOCX to PDF conversion at runtime) on top of the application bits.

6.1 Open Cloud Shell

In the top toolbar of the portal, click the icon that looks like {'>_'}. It sits between the Copilot button and the bell icon. A terminal pane slides up from the bottom.

6.2 First-time setup

If this is your first time using Cloud Shell, a Welcome dialog appears. Pick Bash (not PowerShell). When it asks about storage, pick No storage account required if available, or Mount storage account with the defaults if not. The minimal-cost path is no storage; the session is ephemeral but that is fine for a one-off image build.

6.3 Wait for the prompt

Cloud Shell takes around 20 seconds on a cold start to provision a session. You will end up at a bash prompt that looks like user@Azure:~$.

6.4 Clone the Mike repository

{`git clone https://github.com/Altien/mikeOssAzure.git`}

If your fork lives at a different URL, use that instead. Wait for the clone (around 5 seconds).

6.5 Start the image build

Change into the repo and start the build:

{`cd mikeOssAzure/
az acr build --registry acrmikemini --image backend:latest --file Dockerfile --build-arg NEXT_PUBLIC_API_BASE_URL='' .`}

Note the trailing dot. That is the build context (the current directory). Cloud Shell uploads the source as a tarball to the ACR build agent, which streams build logs back into your Cloud Shell session in real time. The .dockerignore in the repo keeps the upload small (node_modules and build outputs are excluded).

6.6 Wait for the build

The first build takes 5 to 10 minutes; subsequent rebuilds (when you push application changes) are faster because layers cache. You can leave Cloud Shell open and read ahead.

6.7 Import the PostgREST image

Once the backend build is complete, type one more command into Cloud Shell:

{`az acr import --name acrmikemini --source docker.io/postgrest/postgrest:v12.2.3 --image postgrest:v12.2.3`}

This pulls the official PostgREST image from Docker Hub into your private registry. PostgREST will run as a sidecar in the same Container App as the backend (step 9). Mirroring it locally means the Container App pulls everything from a single registry and avoids Docker Hub rate limits.

6.8 Confirm both images are present

Switch tabs to the portal, navigate to acrmikemini, and click Repositories in the left navigation under Services. You should see two entries: backend and postgrest.

6.9 Optional: verify the tags

Click into each repository and confirm the tag: backend should show tag latest; postgrest should show tag v12.2.3. The Last updated timestamp should match when you ran the commands.

You should now have all the values from previous steps plus working backend:latest and postgrest:v12.2.3 images in the registry. No new values are produced by this step. {/* ============================ STEP 7 ============================ */}

Run schema migrations from your laptop

This is the second and last non-portal step. Migrations run from your local clone of the repo against the public Postgres FQDN we created in step 3. The firewall rule for your laptop’s IP from step 3.5 is what allows this connection through.

7.1 Change to the backend folder

Open PowerShell on your laptop and change to the backend folder of your clone:

{`cd ~\\MikeOSSAzure\\backend`}

7.2 Install backend dependencies

Install backend dependencies if you have not already in this checkout:

{`npm install`}

This takes 1 to 2 minutes the first time. Skip if you already have a node_modules directory from earlier development on the repo.

7.3 Set the database URL and run migrations

{`$env:DATABASE_URL = "postgres://mikeadmin:YOUR_PASSWORD@pg-mike-mini.postgres.database.azure.com:5432/postgres?sslmode=require"
npm run migrate:dev`}

Replace YOUR_PASSWORD with the Postgres admin password from step 3. Two details that matter:

The sslmode=require parameter at the end. Azure Postgres rejects non-SSL connections by default; without this you get a “SSL connection is required” or “no pg_hba.conf entry” error.
We use migrate:dev rather than migrate. The migrate script runs the compiled JavaScript from dist; migrate:dev runs the TypeScript source directly via tsx and avoids needing to build the backend first. Either works once you have built the backend, but migrate:dev is simpler for a clean checkout.

7.4 Check the result and common errors

The output streams as each migration runs. Successful output ends with a “Migrations complete” line. node-pg-migrate is idempotent: it records every applied migration in a pgmigrations table and skips anything already there, so re-running the command is safe.

If migrations fail with “extension pgcrypto is not allow-listed”, you missed step 3.9 (allow-listing the extensions). Apply step 3.9 and rerun this step.
If migrations fail with “could not connect to server”, your laptop’s public IP has changed since you set the firewall rule in step 3.5. Find your current IP at api.ipify.org and add a new firewall rule via the Postgres server’s Networking blade.

The pgmigrations table now exists with one row per applied migration. The application schema is in place. If you have psql installed locally, you can confirm with:

{`$env:PGPASSWORD = "YOUR_PASSWORD"
psql -h pg-mike-mini.postgres.database.azure.com -U mikeadmin -d postgres -c "SELECT count(*) FROM pgmigrations;"`}

The count should be the number of migration files in backend/migrations.

{/* ============================ STEP 8 ============================ */}

Deploy the Container App and its environment

What you produce in this step: a running Container App that hosts the backend container, sitting in a newly-created Container Apps Environment that uses your step-2 Log Analytics workspace. The PostgREST sidecar comes in step 9. The FRONTEND_URL and BACKEND_PUBLIC_URL env vars come in step 10, once we know the public FQDN.

Part A. Generate the three application secrets

The application needs three random secrets that you generate yourself: a JWT signing secret, a download URL signing secret, an auth state secret, and a one-time bootstrap token used to sign in to the install configurator. Use the Cloud Shell session you already have open from step 6 (it has openssl and uuidgen ready):

{`JWT_SECRET=$(openssl rand -base64 48)
DOWNLOAD_SECRET=$(openssl rand -base64 32)
AUTH_STATE_SECRET=$(openssl rand -base64 32)
BOOTSTRAP_TOKEN=$(uuidgen)
echo "JWT_SECRET=$JWT_SECRET"
echo "DOWNLOAD_SECRET=$DOWNLOAD_SECRET"
echo "AUTH_STATE_SECRET=$AUTH_STATE_SECRET"
echo "BOOTSTRAP_TOKEN=$BOOTSTRAP_TOKEN"`}

Copy all four values into your password manager or a temporary text file. You will paste them into portal fields in Part D. JWT_SECRET in particular is critical: if you lose it, every signed-in user is signed out and there is no recovery.

Part B. Construct the Postgres connection string

You will need this in Part D. Open a notepad and write out, on one line:

{`postgres://mikeadmin:YOUR_POSTGRES_PASSWORD@pg-mike-mini.postgres.database.azure.com:5432/postgres?sslmode=require`}

Replace YOUR_POSTGRES_PASSWORD with the admin password from step 3. The trailing sslmode=require is the same SSL flag we needed in step 7; Postgres rejects the connection without it. Save this string; you will paste it into a secret called pg-uri in Part D.

Part C. Open the Container App create flow

8.C.1 Open the tile

From the rg-mike-mini overview page, click Create in the top toolbar. In the Marketplace search, type container app and click the Container App tile. Publisher Microsoft, type Azure Service.

Container App Job and Container App Session Pool are different products. Click Create on the plain Container App tile.

The Create blade has six tabs across the top: Basics, Container, Bindings, Ingress, Tags, Review and create. We will fill in Basics, Container and Ingress. Skip the rest.

Part D. Basics tab and inline Environment creation

8.D.1 Top of the Basics tab

Subscription: same as before.
Resource group: rg-mike-mini.
Container app name: backend.
Workload profile: Consumption (the default; do not pick Dedicated for this minimal deploy).
Region: UK South.

8.D.2 Create the Container Apps Environment inline

Click the Create new link below the empty Container Apps Environment dropdown. A side blade opens.

8.D.3 Fill in the environment side blade

Environment name: cae-mike-mini.
Region: UK South.
Environment type: Consumption only.

Click the Monitoring tab inside the side blade. Set Logs destination to Azure Log Analytics and pick law-mike-mini from the workspace dropdown.

Click the Networking tab inside the side blade and confirm Use your own virtual network is set to No. Click Create at the bottom of the side blade.

8.D.4 Back on the main create blade

The side blade closes and the Container Apps Environment dropdown now shows cae-mike-mini selected.

Part E. Container tab

8.E.1 Move to the Container tab

Click Next: Container.

8.E.2 Disable the quickstart image

Untick the Use quickstart image checkbox at the top. We are pulling our own image from ACR.

8.E.3 Pick the image

Image source: Azure Container Registry.
Subscription: same as before.
Registry: pick acrmikemini from the dropdown.
Image: pick backend.
Image tag: pick latest.

The form will read the registry credentials from the ACR resource you set up with admin user enabled in step 5.

8.E.4 Container resource allocation

Set CPU cores to 0.5 and Memory to 1 Gi. The portal often defaults to 0.25 cores and 0.5 Gi which is too small for the backend with LibreOffice and a Node runtime in the same container.

8.E.5 Environment variables and secrets

Scroll down within the Container tab to find the Environment variables section. Add the rows below. Where Source is “Reference a secret”, the dropdown lets you pick the secret name you added. For “Manual entry” rows, you type the value directly.

PG_URI: the Postgres connection string from Part B.
AZURE_STORAGE_CONNECTION_STRING: the storage account connection string from step 4.11.
AZURE_STORAGE_CONTAINER_NAME: manual entry, value documents.
ANTHROPIC_API_KEY: your Anthropic API key, or leave blank if not used.
OPENAI_API_KEY: your OpenAI API key, or leave blank if not used.
GEMINI_API_KEY: your Gemini API key, or leave blank if not used.
azure-openai-key: leave blank for now; populate later if you add Azure OpenAI.
NODE_ENV: manual entry, value production.
PORT: manual entry, value 8080.
AUTH_PROVIDER: manual entry, value local.
SUPABASE_URL: manual entry, value http://localhost:3000.
JWT_SECRET: the JWT secret generated in Part A.
SUPABASE_SECRET_KEY: same value as JWT_SECRET.
DOWNLOAD_SIGNING_SECRET: the download secret from Part A.
INSTALL_BOOTSTRAP_TOKEN: the bootstrap token from Part A.
AUTH_STATE_SECRET: the auth state secret from Part A.

You need at least one model key set. The other rows can be empty strings; the application falls back across providers based on per-user preference. The pg-uri secret intentionally has no env var pointing at it on the backend in this step. The PostgREST sidecar in step 9 is the one that consumes it.

Part F. Ingress tab

8.F.1 Move to Ingress

Click Next: Bindings, then Next: Ingress (skip Bindings, defaults are fine).

8.F.2 Enable and configure ingress

Tick Enabled to enable ingress.
Ingress traffic: Accepting traffic from anywhere.
Ingress type: HTTP.
Transport: Auto.
Insecure connections: leave unticked.
Client certificate mode: Ignore (default).
Target port: 8080. This must match the PORT env var we set in Part E and the EXPOSE 8080 in the Dockerfile.

Part G. Review and create

8.G.1 Validate and create

Click Review and create. Wait for validation. Click Create. Provisioning takes 1 to 3 minutes.

8.G.2 Open the resource and save the URL

When deployment finishes, click Go to resource. You will land on the Container App overview page. The Application Url field on the top right is the FQDN we will use in steps 10 and 11. It will look like backend.kindword-12345678.uksouth.azurecontainerapps.io. Save this value.

Part H. Verify the backend booted

8.H.1 Watch the log stream

Click Log stream in the left navigation under Monitoring. You should see Express startup logs from the backend container. If you see error messages and the container is restarting in a loop, the most common cause is a missing or wrong env var; capture the first error in the stack.

If you see a completely black panel, the app has scaled to zero. Hit the health URL below to bring it back up.

8.H.2 Health check from your laptop

{`curl https://YOUR_BACKEND_FQDN/health`}

You should get back {'{"ok":true}'} or similar. If the request hangs or returns a 502, check the Log stream and the Revisions and replicas blade.

The Container App backend is provisioned and the backend container is running. The PostgREST sidecar is not yet present, so the application UI will not work end to end until step 9 (any request that hits the database via PostgREST will fail with a connection error). The /health endpoint, which does not touch PostgREST, should respond cleanly.

In your notes: the Container App’s Application Url, plus the three application secrets from Part A.

{/* ============================ STEP 9 ============================ */}

Add the PostgREST sidecar

The backend on its own cannot reach the database. It expects to talk to PostgREST at http://localhost:3000 (the SUPABASE_URL we set in step 8). PostgREST is the second container we now add to the same Container App. Containers in the same app share localhost networking, which is what makes the sidecar pattern work without any service discovery.

9.1 Open the backend Container App

From rg-mike-mini, click the backend Container App.

9.2 Open the Containers blade

In the left navigation, expand Application and click Containers.

9.3 Start adding a new container

Click the Create new container link.

9.4 Fill in the Properties tab

Name: postgrest.
Image source: Azure Container Registry.
Authentication: Secrets (not Managed identity). Pick Secrets so the sidecar uses the same admin credentials we configured at app creation. If you pick Managed identity it will fail to pull because we have not granted AcrPull to any MI.
Subscription: same as the backend.
Registry: acrmikemini.azurecr.io.
Image: postgrest.
Image tag: v12.2.3.
Command override: leave empty.
Arguments override: leave empty.
CPU: 0.25. Memory: 0.5 Gi.

9.5 Environment variables tab

Click the Environment variables tab. Add five rows, all manual, no secret references.

PGRST_DB_URI: paste the Postgres connection string you used as PG_URI on the backend (postgres://mikeadmin:...sslmode=require).
PGRST_DB_SCHEMA: public.
PGRST_DB_ANON_ROLE: web_anon.
PGRST_SERVER_PORT: 3000.
PGRST_JWT_SECRET: paste the same JWT secret you used as JWT_SECRET on the backend.

9.6 Save changes as a new revision

Look for a Save or Create button at the top or bottom of the blade. The exact location varies by portal version: sometimes it sits at the very top above Refresh, sometimes at the bottom of the form, and sometimes the workflow is “click Save and a new revision is triggered automatically”.

9.7 Watch the rollout

Watch Revisions and replicas in the left nav. There should now be a new revision with two containers (backend and postgrest), provisioning then Running, while the previous single-container revision drains.

9.8 Verify the sidecar is reachable

From your laptop, hit the application URL again:

{`curl https://YOUR_BACKEND_FQDN/health`}

It should still return ok. The /health endpoint does not actually exercise PostgREST, but it confirms the new revision is taking traffic. To confirm PostgREST itself is wired up, hit a route that does touch it. The simplest is /config:

{`https://YOUR_BACKEND_FQDN/config`}

This returns a JSON object with authProvider, entra, and similar fields. If it returns 500 with a database-related error, PostgREST is unreachable from the backend. The most common cause is a typo in PGRST_DB_URI or a missing sslmode=require.

Two containers in the same Container App, both reporting healthy. /config returns valid JSON. /health still returns ok. The Log stream blade now offers two containers in the Container dropdown (backend and postgrest); switching to the postgrest container shows PostgREST’s startup line “Listening on port 3000”. {/* ============================ STEP 10 ============================ */}

Wire the public URL back into the application

Two env vars on the backend container need to know the Container App’s public FQDN: FRONTEND_URL (used for CORS allow-lists and login-redirect URL construction) and BACKEND_PUBLIC_URL (used to build absolute URLs in OpenID flows).

We could not set them in step 8 because the FQDN does not exist until the Container App is created. Now that the app exists and you have its Application Url, we add them.

In our deploy the frontend is bundled inside the backend image, served by the same Express process. Both env vars get the same value: the public URL of the Container App.

10.1 Open the backend Container App

From rg-mike-mini, click backend.

10.2 Confirm the FQDN

The Application Url field on the right of the Essentials panel shows something like https://backend.kindword-12345678.uksouth.azurecontainerapps.io. Copy that to a notepad; you will paste it twice in 10.4.

10.3 Open the Containers blade

In the left navigation, expand Application and click Containers.

10.4 Add the two new env vars

The Container dropdown should default to backend. If not, select it. Click the Environment variables tab. At the empty row at the bottom, add two new entries:

Name FRONTEND_URL, Value: paste the full Application Url including the https:// prefix and no trailing slash.
Name BACKEND_PUBLIC_URL, Value: paste exactly the same Application Url.

10.5 Save and wait

As with step 9, click Save. The save creates a new revision (your third) and rolls it out. Watch Revisions and replicas; the new revision shows Provisioning, then Running, in 1 to 2 minutes.

10.6 Verify

From your laptop:

{`https://YOUR_BACKEND_FQDN/config`}

The response should be JSON with at minimum an authProvider field. The exact shape varies by config, but it should not 500.

The backend container has 16 env vars (14 from step 8 plus the 2 we just added). The newest revision is Running with both containers healthy. Hitting /config returns JSON. {/* ============================ STEP 11 ============================ */}

Verify with /diag and the local-auth smoke test

This is the milestone we have been aiming at: a deployed application you can sign in to. We do two things here. First we open /diag, the deploy verifier, to confirm the deploy is healthy from the backend’s own perspective. Then we open the application proper and sign in via “Continue locally” to confirm the full vertical works: backend booted, PostgREST sidecar reachable on localhost, schema in place, blob container ready, JWT signing works.

Part A. Verify the deploy with /diag

The MikeOSS fork ships a /diag route specifically to make verification of an Azure deployment fast. It is the right first stop after step 10. No bootstrap token, no Microsoft sign-in, no /api gating: anyone who can reach the backend’s URL can load /diag and see the configuration status.

Open https://YOUR_BACKEND_FQDN/diag in any browser. After cold start the page renders in well under a second.

11.A.1 Walk the env-var checklist

The page groups env vars by category. Every required row should have a green “set” badge. Every secret displays as a partial reveal (first 6 chars, ellipsis, last 4) so you can match against your password manager. Every non-secret displays in full so you can spot a typo at a glance.

What you should see at this stage:

Auth core: AUTH_PROVIDER shows local in full. JWT_SECRET, SUPABASE_SECRET_KEY and AUTH_STATE_SECRET each show partial-reveal masks. All four green.
Entra: section absent. /diag hides this category entirely when AUTH_PROVIDER is not entra; it will appear in step 13.
Database: PG_URI partial-reveal green. SUPABASE_URL showing http://localhost:3000 in full. DATABASE_URL “(not set)” in grey, because that one is only used by the migration job that runs from your laptop, never on the Container App.
Storage: AZURE_STORAGE_CONNECTION_STRING masked green. AZURE_STORAGE_CONTAINER_NAME shows documents in full.
Networking: FRONTEND_URL and BACKEND_PUBLIC_URL each show the full https://YOUR_BACKEND_FQDN. NODE_ENV shows production. PORT shows 8080.
Model providers: a green roll-up banner at the top of the section saying “At least one key is set”. Each individual key (Anthropic, OpenAI, Gemini, Azure OpenAI) green or grey depending on which you configured.
Operator: DOWNLOAD_SIGNING_SECRET and INSTALL_BOOTSTRAP_TOKEN masked green.
Optional: KEY_VAULT_NAME and AZURE_CLIENT_ID grey “(not set)”. Both are production-hardening features we are deliberately skipping.

11.A.2 If anything is red

Red on a row means the env var is required but unset. The most likely culprits at this stage:

PG_URI or AZURE_STORAGE_CONNECTION_STRING red: a typo in step 8 Part E. Re-paste from your notes. PG_URI must end with ?sslmode=require.
Model banner red: no provider key configured. Add at least one from your provider in the env vars.

Fix anything red, save (which creates a new revision), wait for the rollout, reload /diag, repeat until everything is green. When the checklist is green from top to bottom, move on to Part B.

Part B. Smoke-test the running app

11.B.1 Open the app

{`https://YOUR_BACKEND_FQDN/`}

You should see the login page. In local-auth mode the login page shows a “Continue locally” button (or similar copy) which creates an authentication token for any email you type. This is expected; AUTH_PROVIDER=local is meant for first-deploy validation and dev, not for any deployment with real users.

11.B.2 Continue locally

Click Continue locally and type any email address. You can use your own. You should land on the application home page, signed in.

11.B.3 Quick functional check

Click around the app: open the Projects page, the Assistant, Workflows. You do not need to upload a real document; the goal here is to confirm pages render without 500 errors. Any 500 indicates a backend problem; capture the URL and the network-tab response.

Three things confirm the minimal deploy is healthy:

/diag renders the checklist with everything green.
/health and /config return valid responses.
The login page accepts “Continue locally” and lands you in the application.

If all three are green, the entire vertical is wired up. This is the end of the minimal-deploy track.

{/* ============================ STEP 12 ============================ */}

Create the two Entra app registrations

Two app registrations are needed. The first represents the backend API itself, the protected resource that Entra-issued tokens grant access to. The second represents the web client that runs the OpenID code flow against the user’s browser. They sit in your Microsoft Entra ID tenant, not in any resource group; tearing down the resource group does not delete them.

Before you start, capture three values you will need throughout this step. From the Container App backend’s Overview page, copy the Application Url (your BACKEND_FQDN). From the portal’s top right corner, click your account name and note the Directory tenant ID listed in the dropdown; that is your TENANT_ID. The third value, the Backend app’s client ID, you will get after creating the first app reg.

Part A. Create the Backend API app registration

12.A.1 Open Microsoft Entra ID

12.A.2 Go to App registrations

In the left navigation, expand Manage and click App registrations.

12.A.3 New registration

Click + New registration in the top toolbar.

12.A.4 Fill in the form

Name: Mike Backend API.
Supported account types: “Accounts in this organisational directory only (Single tenant)”.
Redirect URI: leave both fields blank. The backend API does not handle redirects.

Click Register.

12.A.5 Capture the client ID

You land on the Mike Backend API overview. Copy the Application (client) ID at the top, save it as BACKEND_APP_ID. You will paste it twice in step 13.

12.A.6 Set the Application ID URI

In the left navigation of this app reg, click Expose an API. Click the Add link next to Application ID URI near the top. The portal proposes api://YOUR_BACKEND_APP_ID; accept the default by clicking Save.

12.A.7 Add the access_as_user scope

Still on the Expose an API page, click + Add a scope. Fill in:

Scope name: access_as_user.
Who can consent: Admins and users.
Admin consent display name: Access Mike Backend API.
Admin consent description: Allows the app to access the Mike backend API as the signed-in user.
User consent display name: Access Mike Backend API.
User consent description: Allows this app to access the Mike backend API.
State: Enabled.

Click Add scope.

Part B. Create the Web Login client app registration

12.B.1 Back to App registrations

Use the breadcrumb at the top or the search bar.

12.B.2 New registration

Click + New registration.

12.B.3 Fill in the form

Name: Mike Web Login.
Supported account types: “Accounts in this organisational directory only (Single tenant)”.
Redirect URI: pick Web from the platform dropdown, then in the URI field paste https://YOUR_BACKEND_FQDN/api/auth/openid-callback/microsoft. Replace YOUR_BACKEND_FQDN with the Container App’s Application Url, no trailing slash before /api.

Click Register.

12.B.4 Capture the client ID

Copy the Application (client) ID from the overview page and save it as WEB_APP_ID.

12.B.5 Add a client secret

In the left navigation, click Certificates & secrets. On the Client secrets tab, click + New client secret.

Description: deploy-time.
Expires: pick 6 months or 12 months. The longer option simplifies operations; you will need to rotate before expiry.

Click Add.

12.B.6 Capture the secret value

Copy the Value column for the new secret (not the Secret ID). This is the only chance to see the value; once you leave the page it is masked forever. Save it as WEB_SECRET. Treat it like a password.

12.B.7 Grant the Web Login app delegated access

In the left navigation, click API permissions. Click + Add a permission. In the side blade, click the APIs my organisation uses tab and filter by Mike. Click Mike Backend API in the list.

12.B.8 Pick the scope

Pick permission type Delegated permissions. Tick the access_as_user scope (the one we created in Part A.7). Click Add permissions at the bottom.

12.B.9 Grant admin consent

Back on the API permissions page, the access_as_user row now shows “Not granted” with a yellow icon. Click Grant admin consent for {''} at the top of the page. Confirm in the dialog. The status flips to a green tick “Granted for {''}”.

If you do not have permission to grant admin consent, the button is greyed out. Ask a Directory admin to do it, or skip and rely on individual user consent at first sign-in (which works in single-tenant mode for users who can self-consent).

You should have, in your notes outside Azure, four new values:

TENANT_ID (your Entra directory tenant ID).
BACKEND_APP_ID (Mike Backend API’s Application (client) ID).
WEB_APP_ID (Mike Web Login’s Application (client) ID).
WEB_SECRET (Mike Web Login’s client secret value).

{/* ============================ STEP 13 ============================ */}

Switch the backend to AUTH_PROVIDER=entra

This step changes the backend container’s env vars to point at the two app registrations you just created and flips AUTH_PROVIDER from local to entra. It also adjusts the PostgREST sidecar’s role and JWT-validation behaviour, because in Entra mode the trust boundary changes: the backend no longer mints JWTs that PostgREST validates; instead the sidecar runs as service_role for every request and trusts that only the backend can reach it on localhost.

You need eight values in front of you before you start. From step 12 you have BACKEND_APP_ID, WEB_APP_ID, WEB_SECRET and TENANT_ID. From step 8 you have BACKEND_FQDN (without protocol or trailing slash; we will prefix https:// where needed). The two group OID values (ENTRA_ADMIN_GROUP_IDS and ENTRA_MEMBER_GROUP_IDS) are optional; you can skip them now and add them later, in which case role assignment falls back to manual via the database.

Part A. Update the backend container’s env vars

13.A.1 Open the env vars table

Container App backend: left navigation Application then Containers, container dropdown backend, tab Environment variables.

13.A.2 Flip AUTH_PROVIDER

Find the existing AUTH_PROVIDER row. Click into the Value field and change local to entra.

13.A.3 Add the eight new Entra rows

Use the Enter name / Enter value placeholders at the bottom of the table. All are manual entries.

ENTRA_TENANT_ID: paste your TENANT_ID.
ENTRA_BACKEND_CLIENT_ID: paste BACKEND_APP_ID.
ENTRA_BACKEND_SCOPE: api://YOUR_BACKEND_APP_ID/access_as_user (paste the Backend client ID into the placeholder).
ENTRA_CLIENT_ID: paste WEB_APP_ID.
ENTRA_CLIENT_SECRET: paste WEB_SECRET (treat this like a password; do not screenshot the unblurred value).
ENTRA_REDIRECT_URI: https://YOUR_BACKEND_FQDN/api/auth/openid-callback/microsoft.
TENANT_ONBOARDING_MODE: auto. Automatically create users on logon.
ENTRA_ADMIN_GROUP_IDS: leave empty for now, or comma-separated Entra group OIDs of admin users.
ENTRA_MEMBER_GROUP_IDS: leave empty for now, or comma-separated Entra group OIDs of regular users.

If you miss any row, the backend will throw at startup; the System log stream tells you which env var is unset.

Part B. Update the PostgREST sidecar

13.B.1 Switch to the postgrest container

Still on the Containers blade. Container dropdown: switch to postgrest. Tab: Environment variables.

13.B.2 Change PGRST_DB_ANON_ROLE

Edit the PGRST_DB_ANON_ROLE row. Change its value from web_anon to service_role.

13.B.3 Clear PGRST_JWT_SECRET

Edit the PGRST_JWT_SECRET row. Clear the value, leaving it as an empty string. This disables JWT validation in PostgREST. Do not delete the row entirely; we want the env var to exist with an empty value, which the sidecar treats as “do not validate JWTs”.

Some portal versions consider an empty value to be invalid and refuse to save. If you hit that, delete the row entirely instead. The PostgREST default behaviour in absence of PGRST_JWT_SECRET is the same as setting it empty: no JWT validation.

Part C. Save and verify rollout

13.C.1 Save

Click Save at the top or bottom of the blade. Saving creates a new revision (your fourth), with both containers updated, and rolls it out.

13.C.2 Watch the rollout

Left navigation: Application then Revisions and replicas. The new revision should provision in 1 to 2 minutes and report Running. The previous revision drains out.

13.C.3 Verify /config reflects entra mode

From your laptop:

{`https://YOUR_BACKEND_FQDN/config`}

The response should now include {'"authProvider":"entra"'} plus an entra object populated with your tenantId and clientId values. If you see {'"authProvider":"local"'} still, something did not save; revisit the env vars table.

Part D. Get and set the admin and member group Object IDs

Microsoft Entra distinguishes between users by group membership. Mike maps two groups to two application roles: admin and member. Group membership flows through Entra-issued tokens as the groups claim, and the backend matches the OIDs in the claim against the comma-separated lists in ENTRA_ADMIN_GROUP_IDS and ENTRA_MEMBER_GROUP_IDS. To make this work you need three things: the groups claim emission turned on for the Backend API app, the OIDs of the two groups you want to use, and those OIDs in the two env vars.

13.D.1 Turn on the groups claim

From the portal search, open Microsoft Entra ID. Go to App registrations, click Mike Backend API in the list. Left navigation: Token configuration. Click + Add groups claim. In the side blade, tick Security groups. Below, under Customise token properties by type, expand both Access and ID and tick Group ID in each. Click Add.

13.D.2 Find the admin group

From the Microsoft Entra ID home, click Groups in the left navigation. Use the search box to find your admin group. If it does not exist yet, create it now: click + New group, set Group type Security, give it a meaningful name like Mike Admins, add yourself and any other admins as members, and click Create. The group needs to be a Security group, not a Microsoft 365 group.

13.D.3 Capture the admin group OID

Click into the admin group. The Overview page shows an Object ID near the top of the Essentials panel; it is a UUID. Copy it. Save it as ADMIN_GROUP_OID.

13.D.4 Repeat for the member group

Find or create a Security group like Mike Members. Copy its Object ID. Save it as MEMBER_GROUP_OID.

13.D.5 Verify the group OIDs are actually in your JWT

Before you paste the OIDs into the env vars and live with whatever they map to, take 30 seconds to confirm they are reachable. Up to this point we have copied OIDs from the Microsoft Entra portal; we have not confirmed that those OIDs appear in the JWT Microsoft will issue for your sign-in. Several Entra group-type quirks (M365 groups, mail-enabled security groups, on-prem AD groups synced via Entra Connect, group-claim overage) will silently strip a group from the token even though the OID looks correct in the portal. /diag is built specifically for this check.

You need to be signed in for /diag to show groups, so sign in first. Open https://YOUR_BACKEND_FQDN/ in a fresh browser tab and complete the Microsoft sign-in flow. You will land on the application home with 403 errors on every API call. That is expected: ENTRA_ADMIN_GROUP_IDS and ENTRA_MEMBER_GROUP_IDS are still empty, so the backend’s role resolver returns no roles and the tenantAccess middleware denies every /api/ request. The 403s look noisy in the browser console; ignore them for now.

Open /diag in another tab. Because you are now signed in, the page renders three new sections below the env-var checklist: a “Groups in your JWT” table, an “Env vars currently in effect” card, and a Status banner.

Look at the Groups in your JWT table. Both the admin OID from 13.D.3 and the member OID from 13.D.4 should be in this list, tagged “unmapped” in the role column until we set the env vars. If both are present, proceed to 13.D.6.

If either OID is missing. The most common cause is that the Backend API app reg’s manifest is set to emit SecurityGroup only, and your group is not classified as a cloud-native Security group. Three group types are silently filtered out: Microsoft 365 groups, mail-enabled security groups, and on-premises AD groups synced via Entra Connect that did not propagate the security identifier.

Three ways to fix it

Path A. Use a clean cloud-native security group. In Microsoft Entra ID, Groups, click + New group, set type Security, name it something deliberate like Mike Admins, add yourself as a member, click Create. Copy the new group’s Object ID from its Overview page. Use that OID as the value for ENTRA_ADMIN_GROUP_IDS in the next step. Sign out and back in. /diag will show the new OID in your JWT groups list. This is the cleaner long-term answer because the group’s purpose is explicit.
Path B. Reuse a cloud-native group you are already in. Walk down the “Groups in your JWT” table on /diag. For each row, click the Open in Entra button next to the OID; it deep-links to the group’s Overview page. Look at the Group type field. Anything labelled Security is a cloud-native security group, which is what we want. Skim each one’s display name and member list, find one whose members are an appropriate set for Mike admins (typically a small IT admins or platform group), copy its Object ID, and use that as ENTRA_ADMIN_GROUP_IDS. The trade-off versus Path A is that you tie Mike’s admin role to a group whose membership was decided elsewhere for some other purpose.
Path C. Broaden the filter. Microsoft Entra ID, App registrations, Mike Backend API, left navigation Manifest. Search the JSON for groupMembershipClaims. The current value is SecurityGroup. Change it to All. Save. Sign out of Mike (clear cookies for the Container App URL or use a fresh incognito window for the next sign-in). Sign back in. Reload /diag. The missing OIDs should now appear. Trade-off: your JWT now also contains distribution lists and any M365 group memberships, which adds noise to /diag’s groups table but does not change role mapping.

Pick whichever fix is appropriate and verify in /diag before moving on. Once the OID you intend to use is present in the “Groups in your JWT” table, proceed to 13.D.6.

13.D.6 Set the two env vars on the backend container

Container App backend, left navigation Application then Containers, container dropdown backend, tab Environment variables. If you put placeholder empty values in 13.A.3, click into the Value field of each row and paste the OID. If those rows do not exist yet, click the empty placeholder row at the bottom and add them.

ENTRA_ADMIN_GROUP_IDS: paste ADMIN_GROUP_OID. If you have multiple admin groups, comma-separate the OIDs with no spaces.
ENTRA_MEMBER_GROUP_IDS: paste MEMBER_GROUP_OID. Same comma-separated format if multiple.

13.D.7 Save and verify

The save creates a new revision and rolls out in 1 to 2 minutes. Reload /diag. The “Env vars currently in effect” card now shows ENTRA_ADMIN_GROUP_IDS with a green “in your token” badge against the OID. The Status banner flips to green saying “Your JWT maps to TenantAdmin, Member. Group setup is correct.” That is the canonical “Entra is fully wired” verification screenshot.

Backend container has 25 env vars. PostgREST container has 4 or 5 env vars depending on whether you cleared or deleted PGRST_JWT_SECRET. The newest revision is Running. /config returns JSON with authProvider entra and your tenant and client IDs visible in the entra object. In Entra, App registrations shows two new entries: Mike Backend API and Mike Web Login. {/* ============================ STEP 14 ============================ */}

Verify Microsoft sign-in

Now that the env vars are wired up and the group OID is set correctly, we sign in for real and confirm the application works for an authenticated user. This is the closing milestone of the Entra phase.

14.1 Sign in via Microsoft

Open https://YOUR_BACKEND_FQDN/ in a fresh browser window (use incognito or clear cookies for the Container App URL so any stale token from the local-auth phase is dropped). Click the Sign in with Microsoft button on the login page. The browser redirects you to login.microsoftonline.com, which prompts for your work account, asks you to consent if this is the first time the app is hitting your tenant, and redirects back to the application.

You should land on the application home, signed in. The header should show your name and email. The application’s UI panes (Projects, Assistant, Workflows) should render without 403 errors in the browser console.

14.2 Verify with /diag

Open https://YOUR_BACKEND_FQDN/diag in another tab. The page should now show all of:

The env-var checklist all-green, including the Entra section that was hidden in step 11 (when AUTH_PROVIDER was local).
A “Sign-in” card showing provider=entra, your tenant ID, your user ID, your email, your display name, and “Resolved roles: TenantAdmin, Member” (or just Member if you used the member group OID).
A “Groups in your JWT” table showing every group OID from your token. The OID you put in ENTRA_ADMIN_GROUP_IDS is tagged “admin” in the role column; everything else is “unmapped”.
An “Env vars currently in effect” section showing ENTRA_ADMIN_GROUP_IDS and ENTRA_MEMBER_GROUP_IDS. The OID(s) you set should have a green “in your token” badge.
A green status banner saying “Your JWT maps to TenantAdmin, Member. Group setup is correct; this user has access.”

That combination of green ticks is the canonical “Entra is fully wired” state.

14.3 If something is wrong

If sign-in failed or /diag shows red badges or unmapped groups, /diag is the place to start. The most common failure modes:

AADSTS50011 redirect URI mismatch on the Microsoft consent screen. The application sent a redirect URI that does not match what you registered. Check step 12 Part B.3 (the Web Login app reg’s redirect URI) and the ENTRA_REDIRECT_URI env var in 13.A.3 are both exactly https://YOUR_BACKEND_FQDN/api/auth/openid-callback/microsoft, with the /api prefix.
Sign-in succeeds but 403 with detail TENANT_UNKNOWN. /diag’s env-var checklist will show TENANT_ONBOARDING_MODE in the Entra section. If it is manual or unset, change it to auto and save.
Sign-in succeeds but 403 GROUP_NOT_WHITELISTED. /diag will show two things: the OIDs in your JWT, and the OIDs in the env vars, with red badges where they do not match. Fix one of them. If your intended admin group’s OID is not in the JWT at all, that is the manifest-filter problem from step 13.D.5; pick Path A, B, or C from there.
Token rejected, “invalid audience” or “invalid issuer”. Cross-reference ENTRA_BACKEND_CLIENT_ID and ENTRA_TENANT_ID against the actual Backend API app reg’s Application (client) ID and your directory tenant ID.
Token rejected, “Token expired”. You signed in then walked away for an hour. Sign out and back in.

Whichever fix you apply: save the env var or app-reg change, wait for the new revision to roll out (1 to 2 minutes for env var, 0 for app-reg changes), reload /diag, retry. Most fixes converge in a single iteration once /diag tells you what is wrong.

Sign-in works end to end against your real Entra tenant.
/diag shows everything green.
The application’s API endpoints return 200s in the browser network tab, not 403s.

When all three are true, the deploy is complete. You could give the URL to a colleague in the same admin group and they would be able to sign in and use it.

{/* ----- closing CTA ----- */}

You made it

That is the whole minimal install.

If you would rather not click through fifteen blades by hand, the same deployment is available as a one-click install from Azure Marketplace, and we are happy to do the hardening pass with you for a fixed fee.

Source on GitHub Book a 30-min scoping call

{/* ----- lightbox modal ----- */} {lightbox && (

setLightbox(null)} style={{ position: 'fixed', inset: 0, zIndex: 2000, background: 'rgba(15,15,15,0.88)', display: 'flex', alignItems: 'center', justifyContent: 'center', padding: 24, cursor: 'zoom-out' }} >

e.stopPropagation()} style={{ maxWidth: '95vw', maxHeight: '95vh', height: 'auto', width: 'auto', objectFit: 'contain', borderRadius: 6, boxShadow: '0 30px 80px rgba(0,0,0,0.5)', background: '#fff', cursor: 'default' }} />

)}

Step {n}. {children}

{children}