Every claim,
verifiable in the source.

Meridian is a read-only visibility layer for your Azure estate. Sign in once, pick a subscription, and every inventory, cost, security, networking, monitoring, and change-tracking view is available under one shell. Every piece of data you see is fetched live from Azure the moment you land on the page — nothing is pre-crawled, nothing is stored on our side, nothing goes stale.

The word that matters most in that first sentence is read-only. Meridian does not have the technical ability to create, modify, or delete Azure resources. This is not a policy we enforce with review or hope — it is enforced by the code, and the enforcement is auditable in a few small files. The rest of this document explains exactly how.

Meridian is a static single-page app with a small set of stateless server-side functions. It carries no database, no queue, no analytics pipeline, no telemetry SDK, and no server-side storage of your Azure data. When you close the tab, the only thing left is the anonymous request log any hosting platform keeps for operational purposes.

Meridian is built for three overlapping audiences:

• Cloud operators who spend half their day in the Azure Portal clicking through blades to check status, spend, and drift. Meridian collapses those clicks into one shell.
• Managed service providers (MSPs) who manage multiple customer tenants. Meridian supports Azure Lighthouse and walks the full delegated-subscription list; every subscription is marked HOME or delegated.
• Security and audit teams who need a read-only, auditable view of security posture — CIS control status, orphaned resources, drift since last review, WAF review, blast radius — without granting anyone Contributor-or-higher rights.

None of these audiences needs to install anything in their Azure. The only Azure-side prerequisite is the Reader role on each subscription being inspected.

Meridian offers two ways to authenticate. Both are read-only.

Whichever method you pick, the credentials that reach Meridian's backend are stored inside an encrypted HttpOnly cookie set on your browser and never persisted anywhere else. The plaintext values never touch a log line, a database, or a filesystem.

Not every team can grant even read-only access on day one. For those cases Meridian has File mode: upload an exported ARM template or a Terraform state file and the same network and configuration analysis runs against it — no Azure connection, no credentials.

Supported inputs:

• Terraform state — a .tfstate file or terraform show -json output. Most accurate, because state holds fully-resolved values and real resource IDs.
• Azure ARM JSON — an az resource list export, an ARM REST list, an exported template, or a single resource.

For deployment templates, Meridian evaluates the ARM expression language — parameters(), variables(), concat(), resourceId() and friends — so resource names and references resolve instead of showing raw [parameters('…')] strings.

Throughout File mode a persistent banner marks the data as file-based — naming the file and stamping the “as of” time — so it is never mistaken for a live tenant view.

When you open any inventory or cost view — say, Virtual Machines — the request flow is:

1. 1. Browser → Meridian backend. Your browser makes a request to /api/arm/<subscription>/<path>. The session cookie is attached so the server can identify the signed-in user.
2. 2. Cookie decrypt. The Function decrypts the cookie in-memory (AES-GCM, 256-bit key). It reads either the Service Principal credentials or the refresh token, then discards them from memory after the response returns.
3. 3. Token acquisition. The function calls Azure AD to mint (or refresh) an ARM access token. Tokens are cached in a short-lived edge cache for their natural lifetime (~1 hour) so we don't hammer Azure AD.
4. 4. Read-only ARM proxy. The Function rejects any request with a non-GET verb before it leaves the server. For allowed requests, it forwards a GET to management.azure.com with the freshly minted token.
5. 5. Response → browser. The ARM response is streamed back to your browser as JSON. No copy is retained on our side.

The only outbound requests Meridian ever makes are to:

• — login.microsoftonline.com (Azure AD token endpoints)
• — management.azure.com (Azure Resource Manager)
• — prices.azure.com (Microsoft's public Retail Prices API — no auth, no data sent)

There is no third-party analytics, no telemetry endpoint, no CDN script from an unrelated vendor. Every outbound host is a Microsoft property.

The core promise is that Meridian cannot mutate your Azure. That promise rests on four independent defensive layers. All four must fail simultaneously for a write to happen — and by construction, the second and third layers are impossible to bypass at all.

A full audit of what is stored where, for how long, and how it is protected. There is no other state.

Explicit boundaries make the app easier to reason about. Meridian deliberately does not:

• Write to Azure. No creates, no updates, no deletes, no policy assignments, no role assignments. See the four-layer guarantee.
• Ship third-party analytics. No Google Analytics, no Segment, no PostHog, no LinkedIn pixel, no Facebook tag. The only network destinations are Microsoft's identity and management endpoints.
• Retain your data on our servers. Snapshots and baselines live in your browser. Prices and tokens cached at the edge are anonymous and short-lived. Nothing about your estate is retained past the moment you close the tab.
• Aggregate customer data. There is no shared training set, no cross-tenant model, no leaderboard. Your numbers are yours alone.
• Call an LLM or external AI service by default. The intelligence signals (right-sizing verdict, drift risk, anomaly detection) are pure rule-based and statistical classifiers running in your browser. No inference is farmed out.
• Require an agent in your environment. Nothing to install in Azure. Nothing to install on a bastion. Nothing running as a scheduled task.

Three signals turn raw inventory into "here is what to act on." All three run entirely in your browser against data Meridian has already fetched. None involves a third-party service or a machine learning model over the network.

No black box, no LLM guesswork — just proven techniques turned into answers your team can act on. Here is what that looks like in practice:

Beyond the always-on views, Meridian ships a set of focused tools that answer the specific questions you ask when you're shipping a change or chasing an incident. Each one takes a question you'd normally solve by clicking through a dozen Portal blades and turns it into a single screen. All of them are read-only.

A static single-page app plus a small set of stateless serverless functions on a managed edge platform — no always-on server, no VM or operating system to patch, and all traffic HTTPS end-to-end. That is the entire footprint.

A one-page summary a security reviewer can use to sign off on Meridian. Each question links to the section that answers it.

How does this differ from just using the Azure Portal?+

The Portal shows one blade at a time. Meridian aggregates 22 views under one shell, adds live-priced cost intelligence, cross-subscription rollups, drift snapshots, and three intelligence signals — all read-only, all in one place.

Can we evaluate Meridian without giving it any Azure access?+

Yes — use File mode. Upload an exported ARM template or a Terraform state file (.tfstate / terraform show -json) and Meridian runs its network topology, subnet reachability, NSG/WAF and IPAM analysis entirely in your browser. Nothing is uploaded and no credentials are needed. Cost and metrics stay disabled because that data isn't in an infrastructure file.

Is there a hosted SaaS version, or must we self-host?+

The public hosted version lives at meridian.cloudcanvas.info. You can also deploy your own private instance in a few minutes — it's a static app plus stateless functions, so it runs on any modern edge or serverless platform.

How is authentication rotated?+

Sessions expire after 4 hours regardless of activity. To sign everyone out on demand, bump the SESSION_EPOCH environment variable — every previously-issued cookie fails validation on the next request. As a nuclear option, rotating SESSION_SECRET invalidates sessions and rotates the encryption key at the same time.

Can the app be air-gapped or run privately?+

Yes. The app is a static bundle plus stateless functions, both of which can be deployed to a private, internally-routed environment so only your users can reach it — provided the function environment can still reach the Azure endpoints it reads from.

What if a developer accidentally introduces a write path?+

It would show up as a diff in code review. The ARM proxy's GET-only check is a single small function, easy to spot. Introducing a write-capable Azure SDK is also a visible dependency change reviewers can catch.

What is the incident-response process if something goes wrong?+

Deployments are immutable and can be rolled back instantly from the hosting console. Because Meridian holds no server-side state, a rollback cannot corrupt any customer data. Revoking every session takes under a minute via the session controls.