---
title: "Use the console"
---

> Documentation Index
> Fetch the complete documentation index at: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Use the console

The console is the primary day-to-day view of an organization. It keeps
organization resources, deployment history, quotas, and operational signals in
one place while Wrangler remains the deployment interface.

Open <http://console.ermahgerd.localhost:8081> for tenant resources, or
<http://admin.ermahgerd.localhost:8082> for platform administration. The local bootstrap
account (`owner@localhost` / `local-owner-password`) can sign in to both.
The portals have independent sessions: signing out of one leaves the other
signed in. Organization owners are not automatically platform administrators.
The minimal public landing page is <http://ermahgerd.localhost:8080>.

## Choose an organization

After signing in, the organization directory is the account-level home. A
customer-invited account can create an organization there; an account created
through a team invitation can only enter organizations it has joined. Select an
organization's linked name to enter its resource views.
Until an organization is selected, the sidebar contains only account-level
navigation.

![Organization directory with account-level navigation](/media/screenshots/organization-directory.png)

Inside an organization, the overview gives a compact inventory of Workers,
members, credentials, runtime capacity, and recent deployments. Use the sidebar
to move between the organization’s resources; its URL always identifies the
current organization and view, so pages can be refreshed, bookmarked, and
shared.

Resource tables show 25 rows by default and offer 10, 25, 50, 100, and 150-row
page sizes when needed. Page number and page size remain in the URL alongside
the view's other filters, so reloading or sharing a long inventory returns to
the same place.

The navigation follows the platform model: **Compute**, **Data**, **Media**, **AI**,
**Messaging**, **Security**, and **Management** group related tenant resources.
**AI** contains provider connections and vector indexes; it is where an
organization brings its own provider account before a Worker uses `env.AI`.
Security →
Access manages protected Worker hostnames, reusable groups, application
policies, scoped service credentials, and access events. The separate
administrator portal contains only the **Platform** navigation: overview,
organizations, customers, fleet, and events and logs. Administrators do not need a tenant
membership to use it.

![Organization overview showing its resources and recent Worker deployments](/media/screenshots/console-overview.png)

## Inspect a Worker before or after a deployment

Select a Worker to see its active version and revision history. Use the
**Deployments** tab for one revision’s deployment metadata and the
**Observability** tab for traffic, latency, and recent application events. The
console does not deploy source code: deploy with Wrangler, then use this view to
inspect the result or roll back to a prior revision.

Workers with native Durable Object bindings also expose a **Durable Objects**
tab. It shows the stable shared-pool placement, Wrangler migration tag,
namespace identities, observed native storage, and bounded lifecycle history.
For the organization-wide view, open **Compute → Durable Objects**. Namespace
names link to a focused detail with storage, ownership, migration, and lifecycle
pages. Stored object counts describe persisted databases, not running instances.

![Organization Durable Object namespace inventory](/media/screenshots/durable-objects.png)

The Worker overview also lists its event triggers. HTTP ingress and configured
queue consumers are explicit, and background activity is visible in the
Observability tab as invocation rate and outcome. Queue consumers also receive
queue-service handler duration percentiles. Shared-pool CPU and memory are shown
as capacity context, not fictional per-Worker allocation. Configured Cron
Triggers link to **Compute → Schedules**. This page lists scheduled Workers,
next deliveries, and current state. Open a Worker to inspect each Cron expression
and its last outcome, pause or resume delivery, or continue into scheduled
invocation telemetry and logs. An operational pause survives deployments;
expressions are still managed in Wrangler. See [Schedules](/schedules/).

![Scheduled Worker details and delivery controls](/media/screenshots/schedules.png)

![Worker overview with active revision and version history](/media/screenshots/worker-overview.png)

## Work with data and AI

**Media → Images** separates transformation usage, bound Workers, and recent
activity into focused tabs. Time range and table selections stay in the URL.
The monthly allowance comes from quota metering; charts and recent operations
come from organization-scoped telemetry and can have a shorter retention window.
Images does not store photos: browse originals and renditions in **Storage**.

![Organization Images transformation usage](/media/screenshots/images.png)

**Storage** presents buckets as navigable object browsers. Prefixes behave as
folders, object details expose metadata and version information, and destructive
operations require explicit confirmation. The same bucket can be used by an
S3-compatible client or bound to a Worker as R2-style storage.

![Organization storage browser and its S3 endpoint](/media/screenshots/storage-browser.png)

**Queues** makes delivery state visible to the organization that owns it. The
detail view combines backlog and activity with consumer settings, pending
messages, and durable delivery events. Pausing live updates freezes the view
while investigating without changing queue processing.

![Organization queue inventory and delivery-state summary](/media/screenshots/queue-overview.png)

**Key-value** provides tenant-scoped namespaces for small configuration and
coordination values. The namespace page supports prefix browsing, UTF-8 value
and JSON metadata inspection, expiration, activity history, and deliberate
rename or deletion. Values remain subject to the service's 64 KiB limit; use
Storage for objects and large payloads.

**AI → Models** stores a connection to an organization-owned OpenAI, Anthropic,
or Fireworks account. The console never reveals a saved provider credential.
Workers use the native `AI` binding instead. **Vector indexes** creates and
inspects the indexes those Workers can bind through Wrangler. See [AI and vector
search](/ai-and-vector-search/) for the binding and supported provider calls.

## Review limits and appliance health

**Usage & limits** groups configured allowances, authoritative usage, and
current enforcement state by platform service. Platform administrators can set
or reset explicit allowance overrides in the administrator portal. The platform
records the actor and changed values automatically; no free-form justification
is required.

![Organization usage and configured limits](/media/screenshots/usage-limits.png)

In the administrator portal, **Platform → Overview** summarizes platform-owned
traffic and service posture, **Fleet** shows per-host capacity and placed
services, and **Events & logs** exposes lifecycle evidence and selected service
logs. These views deliberately exclude individual tenant failures from platform
health.

![Platform overview with current platform-owned activity](/media/screenshots/platform-overview.png)

![Fleet inventory with current host pressure](/media/screenshots/platform-fleet.png)

![Platform-wide observability for platform operators](/media/screenshots/appliance-observability.png)

## Portal isolation and deployment

Ansible installs separate console processes and service accounts:
`ermahgerd-landing` (control WireGuard port 9073),
`ermahgerd-console` (control WireGuard port 9070), and
`ermahgerd-admin-console` (control WireGuard port 9071). Lima forwards them to
the public ingress and host loopback ports 8081 and 8082. Each authenticated
portal uses its own host-only, HttpOnly,
SameSite=Strict cookie and exact Origin checks for mutations. The tenant
listener has no platform API routes, including platform telemetry.

Identity also has separate tenant and administrator listeners. The private
administrator identity API (control WireGuard port 9081) is not forwarded by Lima.
Identity persists each session's audience and rejects cross-portal use;
organization API tokens remain unchanged. Upgrading from the unified console
revokes old browser sessions, so sign in again after provisioning.

For an existing VM, apply the new Lima port-forward configuration before
provisioning; changing the repository template alone does not update an existing
instance. New VMs receive it automatically through `make up`.

For a remotely accessible installation, set `console_origin` and
`admin_console_origin` to distinct HTTPS hostnames and enable
`console_cookie_secure`. Expose the tenant service through the public listener;
expose the administrator service only through a private listener/VPN. Keep
identity, quotas, and other backing APIs private. Both listen addresses are
independently configurable. Hostnames alone do not provide network isolation;
the local setup does not install a VPN.

## Refresh the documentation images

The images above are generated from a real, running local appliance. After
`make up`, refresh them with:

```sh
make docs-screenshots
```

The capture only reads the appliance and replaces the curated images in
`docs/screenshots/`.

Source: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/console/index.mdx