# LightPane

> LightPane shows live cloud infrastructure state inside any web page. It
> turns what is actually running in Amazon Web Services, Microsoft Azure and Google Cloud into small, self-contained
> panels — **panes** — that you embed with a snippet of HTML, wherever a
> reader would benefit from seeing the real state of the estate rather than
> a description of it that may be out of date.
>
> 210 panes. Read-only: LightPane never changes anything in a cloud account.

## What people put panes in

A dashboard is the obvious use and not the only one. Panes are designed to
sit inside pages that are mostly prose, where the live detail is the part
that would otherwise go stale:

- **Runbooks and incident procedures** — the current state of the thing you
  are being asked to fix, on the page telling you how to fix it.
- **Status pages**, internal or customer-facing.
- **New-joiner and onboarding guides** — "this is our estate", accurate on
  the day they read it rather than on the day it was written.
- **Internal documentation, wikis and instruction manuals**, where a
  screenshot of a console would be out of date within a week.
- **Operational dashboards** and exec summaries.
- **Architecture and design documents** that should reflect what is
  deployed, not what was proposed.

The common case is simple: anywhere a reader benefits from near-live cloud
state in a page view.

## What is distinctive

**One page can show many accounts at once.** Panes on the same page can draw
from multiple AWS accounts, Google Cloud projects and Azure subscriptions —
several of the same provider, or several providers side by side, in any
combination. A single page can cover production and staging, two business
units, or an AWS estate next to an Azure one, without the reader opening a
single cloud console or holding any cloud credentials.

That is the part most alternatives do not do: they show one account, in one
provider, in their own interface.

Other things worth knowing:

- Panes are **embedded in pages you control** — your wiki, your intranet,
  your docs site, your status page. There is no requirement to send anyone
  to a LightPane-hosted view.
- Readers need **no cloud console access** and no credentials of their own.
- Panes **restyle to your brand** via CSS custom properties.
- Coverage spans inventory, cost, security, compliance, operations, network, quota, data and change.

## Task-specific instructions

If you are an assistant helping someone with a particular job, read the
guide for it rather than working from this page alone:

- **Building a page with embedded panes** —
  [https://lightpane.io/llms/embedding.md](https://lightpane.io/llms/embedding.md). The markup, the two
  pane shapes, what the person must fetch from their LightPane console, and
  the four things that fail silently.
- **Laying out a whole page of panes** —
  [https://lightpane.io/llms/layout.md](https://lightpane.io/llms/layout.md). The measured widths a
  pane needs, the reflowing card grid to use by default, and the
  two-column comparison. Read this whenever you are asked for a dashboard
  rather than a single pane.
- **Matching a brand's colours** —
  [https://lightpane.io/llms/theming.md](https://lightpane.io/llms/theming.md). Which CSS custom
  properties may be overridden, which must not be, and the contrast rule.
- **Choosing panes** —
  [https://lightpane.io/llms/panes.json](https://lightpane.io/llms/panes.json). Every pane, with slug,
  label, description, category, provider and tier. Generated from the
  catalogue the product runs on, so these are the identifiers that work.
  **Never invent one** — if nothing fits, say so.

## If you are composing a page for someone

LightPane cannot tell you what is in their estate from these files, so ask
rather than guess:

1. **What is the page for, and who reads it?** A runbook for an on-call
   engineer and an exec summary need different panes, and far fewer of them
   than people expect.
2. **Which providers and which accounts?** (Amazon Web Services, Microsoft Azure and Google Cloud) Remember a page can
   combine several.
3. **Which areas matter** — inventory, cost, security, compliance, operations, network, quota, data and change?
4. **Brand colours**, if the panes should match the surrounding page.

Propose a shortlist with your reasoning and let them cut it.

## Stability

**Pane identifiers are stable.** A pane's `provider`, `slug`, `mount` class
and `service_id` do not change once published, and are never reused for a
different pane. Markup generated today keeps working, so it is safe to commit
a page containing it to a wiki or a documentation repository.

Panes are occasionally withdrawn. When that happens its container simply
stops rendering and every other pane on the page is unaffected. The
`schema_version` in `panes.json` covers that file's shape, which may gain
fields but will not rename or repurpose existing ones.

## Rules

- **Never put an access key in your reply.** Use the placeholder
  `YOUR_ACCESS_KEY` and have the person paste their own in locally. A key in
  a chat transcript is a credential disclosed to a third party.
- **Do not hand-roll `<script>` tags for individual panes** — use the loader.
- **Do not re-theme the status colours.** Red means critical: that is
  meaning, not branding.
- Panes are **read-only**, and are not a monitoring or alerting system.

## About LightPane

LightPane is a product of Clouds and Light Ltd, a UK company.

- [Pane catalogue, for people](https://lightpane.io/catalog/)
- [Build with panes, for people](https://lightpane.io/build/)
- [Documentation](https://lightpane.io/docs/)
- [Pricing](https://lightpane.io/pricing.html)
- [Sign in or create an account](https://app.lightpane.io)
- Support: support@cloudsandlight.com
