Deployment detail
For administrators looking after a Studio deployment, and the identity administrator setting up sign-in for an unlinked one. Viewers read every view; retention, network and certificate changes, rollback, pause, resume and delete need the Owner or Operator tier or the DeploymentOperator Role.
Before you start: open Fleet and click a deployment. It opens on Overview; View also offers Jobs (Jobs, progress and failures), Identity and Health and Analytics.
Read the header
Every view shares Name (the name you typed, with the app domain beneath), Deployment ID, Account, Version and Status (the Fleet's values; " (stale)" after 15 minutes without a health check) and three actions. Pause and Resume ask you to confirm; Delete asks you to type the name it shows, which is the deployment's app domain (for example studio.example.com). While a job runs the Overview re-reads every 15 seconds; an unknown id shows "No deployment with this id" and Back to Fleet. Pause stops every task and sign-in until you Resume; nothing is deleted. Delete starts an uninstall (Deleting a deployment) and, when the last job failed, replaces that job. Both are disabled while a job runs.
Read Deployment details and Configuration
Deployment details shows Account, Region, Version (with Roll back… beside it, below), Licence id and Licence state; a dash means not yet recorded (wizard fields at launch, configuration fields when a reconfigure or upgrade applies them).
Configuration shows what the deployment was created with:
| Row | Values |
|---|---|
| Release channel | The channel the release came from. |
| Ownership | Standard (each user owns and sees only their own resources) or Governed (everyone assigned shares every resource and workspace file; required for Programmatic Access). |
| Deployment size, Redis node type, Coordinator model, Worker model, Chat-title model, Inference zone, Neo4j mode, Session timeout (seconds), Environment | The running values. Each model reads as product name and id, such as "Claude Opus 5.5 · anthropic.claude-opus-5-5"; a model not recorded yet reads "—" until the deployment's next job records it. A size or Redis node type left blank in the wizard reads as its default, such as "Default: standard". Models are shown here, not edited (Supported models). |
| Run data retention | "N days", or "90 days (default)". |
| PII redaction default | Off, Mask or Hash; workflows and runs can tighten it, never loosen it. |
| Payload template | "Studio", or "minimal target stack (not Studio)" for a test deployment. |
Change run data retention
Change… opens Change run data retention (needs the reconfigure permission; disabled while a job runs).
- Enter a whole number of days in Run data retention (days), 1 to 3650; older run inputs and outputs are deleted automatically.
- Click Apply (enabled when the value is valid and differs from the current one). The console opens the update job in Jobs; Studio users see the update screen until it finishes.
Roll back to the restore point
Every update and configuration change captures a restore point before it changes anything: the release and task definitions each service was running. Roll back… beside Version returns the deployment's services to the restore point of the last update or configuration change that completed. It needs the rollback permission (the Owner or Operator tier, or the DeploymentOperator Role) and is disabled while a job holds the deployment.
- Click Roll back…. The dialog Roll back to the restore point names it: "This deployment's services go back to release
<version>, as they were at<time>, when its last completed update started." - Click Roll back. A rollback job starts and opens in Jobs; its services restart on the earlier versions while it runs, and the action is recorded in Audit as
deployment.rollback.triggered.
With no restore point yet the dialog reads "This deployment has no restore point yet. One is captured when an update starts, and it can be rolled back to once that update completes." A failed update or reconfiguration is rolled back automatically; this button is for undoing one that completed. On a private deployment the rollback re-applies the recorded network lists and re-checks the attachment and routes.
What a rollback leaves as it is:
- Studio's web app. The browser app stays on the newer release until the next update; the services go back.
- The next restore point's label. After you roll back and then update again, the restore point that update captures can name the release you had rolled back from, while it holds the services you had rolled back to; Roll back… then names that release. The Studio version in the footer of Studio's sidebar shows the release the services run. An update to a newer release brings the two back in line.
- The jobs list wording. A rollback you started and then stopped can read "The update failed and the automatic rollback also failed." in Jobs, although the update itself had completed. Open the job for its own steps and status.
- The route that drops unlisted private ranges. On a private deployment whose outbound traffic goes through your Transit Gateway, rolling back to a restore point captured before Studio 2.0.18 removes that route, its prefix list and its network interface, because that release did not have them. The next update to 2.0.18 or later creates them again. A deployment installed on 2.0.18 or later never has such a restore point.
Read Network on the Overview
Network ("How users reach this deployment, and what its agents can reach.") shows, for every deployment:
| Row | Shows |
|---|---|
| Network access | "Private · internal load balancer", or "Public (CloudFront, existing)" for a deployment created before private network access |
| VPC | The VPC ID and its range. Associate your private hosted zone or resolver rules with this VPC so the app domain resolves inside your network |
| Subnets | The subnets in the VPC range |
| Outbound internet traffic | "Through AlphaAgent's NAT gateway" or "Through your Transit Gateway (your firewall)", with Firewall egress IP addresses for the latter |
A private deployment adds Transit Gateway, Attachment (its ID and state: Available, Waiting for acceptance, Being created, Rejected, Deleted or Failed), Network check, User access ranges, Internal service ranges and Internal service ports. Network check is the health check's last reading between jobs: "Healthy · N of N ranges routed", or "Needs attention" with the failure's message, each range whose route is missing or blackholed, and the remediation. After a change to the lists stopped partway (abandoned, failed or waiting for an answer), it reads "This deployment's private network carries ranges or ports from a change that did not finish, so they differ from the lists shown here."; until you act, traffic follows the ranges and ports that change applied. While a job holds the deployment it names that job instead.
Change the ranges and ports
Edit under Network opens Change private network access with User access ranges, Internal service ranges and Internal service ports (the same rules as the wizard; a range removed here stops connectors and agent code reaching it). "Applying a change runs an update job on this deployment; Studio users see the update screen while it runs." Apply is enabled when a value changed. When the attachment is not Available, or Network check reads "Needs attention", the button reads Apply again and runs the same job with the same values: it requests a new attachment if the old one is gone, puts back any route deleted outside AlphaAgent, and applies the lists shown here over any left by a change that did not finish. If that change is still stopped in Jobs, continue it there or abandon it first. Network access, the VPC range, the Transit Gateway and outbound traffic cannot be changed.
Connectors on the Overview
The Connectors card shows Sign-in redirect URI, https://<app domain>/data-connector/connectors/oauth/callback, with Copy: "Register this address in OAuth and Microsoft Entra app registrations used by connectors." It is the one address this Studio uses for every connector where each person signs in. Under it, each MCP connector in the Studio is listed as Working or Not responding since time. Studio checks about every 15 minutes, and a connector that needs a credential is not checked (Connector policy, credentials and activity). The address appears once the deployment has an app domain, and the card is read-only.
Trusted certificate authorities
Trusted certificate authorities ("Certificate authorities agents trust, in addition to public ones, when they call your internal services.") appears on every deployment. With none: "None. Agents trust public certificate authorities only." Otherwise one row per certificate: its subject, "Issued by <issuer> · Expires <date>", the SHA-256 fingerprint on hover, "Expires in N days. Add its replacement before then." within 30 days, and "Expired on <date>. Remove it, or add its replacement." after.
Edit opens Change trusted certificate authorities: paste PEM certificates or Upload PEM file (.pem, .crt or .cer, PEM or DER), see each one listed with subject, issuer, expiry and fingerprint, and Remove any. Add your root CA, the issuing CA that signed your services' certificates, or both; each certificate must be a CA (not your service's own certificate), within its dates, RSA 2048 or larger or EC P-256 or P-384, up to 20 certificates and 64 KB in total. Apply runs an update job: "Agents use the new certificates once the job has finished." Every change is recorded in Audit as deployment.trusted_ca.changed. Agents use them for REST, MCP and SQL connectors (verify-ca and verify-full), agent code and web browsing; never for licensing, AWS or sign-in. An untrusted internal certificate reads "The certificate for <host> is not issued by a trusted authority. If it comes from your own CA, an administrator can add it under Trusted certificate authorities on the deployment's Overview in Organisations."
Read Identity and Endpoints on the Overview
Identity shows the Identity provider ("<tenant> (Microsoft Entra ID)" as a link, or "none linked"), Entra app id, Pool id and SP entity id, "assigned once SSO provisioning runs" until then.
Endpoints ("Where the deployment is reachable, and the one DNS record you create for it.") shows the App domain, the DNS target and the Load balancer hostname.
- Private: the DNS target is the internal load balancer ("appears once the Stateless step has finished" before it exists). "Point the app domain's record in the private DNS zone your users resolve at the DNS target above, and associate that zone with this deployment's VPC; the change is yours to make."
- Public (CloudFront, existing): DNS target (CNAME) is the distribution domain ("appears once the Edge step has finished, usually 20 to 25 minutes in" before it exists; "Interim" while the distribution is still being created), and CloudFront front door reads "Always on · waiting for the CNAME" until your record resolves to the distribution, then "Always on · origin locked".
- After an uninstall the DNS target reads none, and a note names the record to remove from your zone.
Use the Identity view
Linked. The card reads "SSO provisioned automatically via <tenant> (Microsoft Entra ID)."; a failed attempt names the failure with View job history. Who can sign in lists every assigned person and group (Name, Type), 20 at a time, with the seat count "N of M user(s)". "Search by name or email" searches your whole directory; when the part searched so far has no match it reads "No match yet" with Keep searching. Assignments change from Manage in Identity & Access Management → (Users, groups and roles), not here; a group that grew after assignment is flagged with "Remove users to return under the cap."
Not linked. Use an identity provider lists your connected tenants; click one to link it. With none, connect one first or follow the manual runbook.
Follow the manual SAML runbook
For an unlinked deployment the Identity view carries everything your Microsoft Entra administrator needs; the URL is shareable. Copy all as text and Download signing certificate (.cer) sit at the top. The strip at the top reads waiting (values fill in within about a minute), ready (the job is parked for your metadata, not failed; nothing expires for 14 days) or a problem to check on the progress page. Seven steps, each with copy buttons; the Entra clicks are on Connect your identity provider and Sign in with Entra ID:
- Create a non-gallery SAML Enterprise Application
- Paste the basic SAML configuration (Identifier, Reply URL, Sign-on URL, Logout URL)
- Set NameID to a persistent, unchanging attribute
- Add the required claims
- Upload our signing certificate (optional, but do it)
- Assign the users and groups
- Send us the App Federation Metadata URL
- A mutable NameID (email or UPN) silently duplicates users and orphans their work.
- Without the signing certificate under SAML Certificates → Verification certificates, single logout fails silently; without the Logout URL, signing out leaves the Entra session open.
Read Services and Analytics
Choose Health and Analytics in the View selector.
Services lists each service's Running and desired task counts; on a paused deployment every service is at 0, "paused, not broken".
Analytics charts token usage by period (24h, 7d default, 30d), granularity (Hourly, Daily) and split (By model, By activity): UTC buckets by turn finish, the first partial, billable prompt tokens only. The activity labels are the metering event kinds listed on What leaves your account. Export CSV downloads the buckets with user id, kind, model and the four token counts; without per-user permission it falls back to the chart's series.
User attribution lists the same rows by principal with its own Export CSV; principals are people, API keys and AlphaAgent's own runs such as a scheduled workflow. Search by user matches the start of a person's email, an API key's ID or name, or the label the table shows.
Read Health
Health draws CPU utilization, Memory utilization, Network in and Network out over 1h (default), 3h, 12h, 1d, 3d or 1 week, refreshing every 60 seconds. Logs: the card links to the AWS ECS console.
What you should see
- An old
/settingsaddress opens the Overview. A reconfigure is the retention, network list or certificate change. - No update button: updates arrive through Update Manager. Roll back… undoes the last completed one; Jobs lists Upgrade, Reconfigure and Rollback jobs.
- Analytics and User attribution share one period and count the same rows.
Notes
- Ownership, Environment, network access, the VPC range, the Transit Gateway and outbound traffic are fixed after launch; sizing, Redis node type, models and the PII redaction default change only through a Fleet Configuration Template, which carries no network settings. An existing public deployment keeps its front door. The DNS record and your private zone's association are yours; the console never changes them.
- User attribution needs the Owner or Operator tier. Usage is copied from the deployment every two minutes. Health charts read your account's CloudWatch metrics through the registration role; the banner "Your account role needs updating for Health metrics to work." means re-run the account template from Accounts, then Verify.
- A blocked licence serves no turns, so a busy deployment can chart nothing.