Stateless HTTP apps can be configured with minimum and maximum Web replicas and a CPU target. Activation is operator-assisted and requires a capacity and runtime review.
The maximum plus one rolling-update Pod is reserved within your workspace allowance. Updates preserve the current replica count, while deliberate stops stay stopped.
Scale-down waits for sustained lower demand. Databases and apps with local persistent volumes remain outside this feature; it does not automatically enable scaling for existing apps.
Hover over an app's traffic chart to see the time, estimated request count, error rate and response time for that five-minute interval.
Counts on the chart are labeled requests / 5 min, while the summary is labeled 12h total. You can also tap the chart or focus it and use the arrow keys. Missing observations stay unknown rather than appearing as zero; app cards keep their compact layout.
Operator-assisted custom domains are now available for HTTP apps, alongside their existing Pangea addresses.
Activation requires per-app DNS ownership verification, an approved HTTPS route and a fresh check of the app identity. Your app's Host and cookies are preserved.
Domain setup is operator-assisted; adding a name does not immediately publish it. Wildcard domains, automatic hostname reassignment and self-service domain changes are not included.
Independent safety checks run concurrently to reduce brief pauses when accepting new app operations.
Safety checks count their running time toward the next refresh interval, avoiding an extra wait after a longer check.
Every required check must still complete within the existing freshness limit. Changed resources, failed checks and expired permissions continue to block new work.
An operator-enrolled delivery path can use a project's published image without rebuilding its source in the app deployment step.
Deployments retain generation checks, shared capacity limits, readiness checks and recovery. Only a fixed image digest from the same project's repository is accepted.
The CLI connection's request validation is also prepared for this delivery path and rolling app configuration. Existing workspace and credential checks still apply.
Operators can also prepare exact private service destinations for an app. Credentials and network access require separate review and activation; this does not enable private-network access or image delivery for all projects.
After an interrupted app is confirmed stopped, other apps in the workspace can accept deployments again.
The platform checks the stop record, the stopped deployment and the absence of remaining app, build and data-helper Pods. Network, storage and shared capacity checks still apply.
The interrupted app stays blocked for inspection. Its failed operation is not retried, and its data and recovery records are retained. Unconfirmed termination still blocks new work.
Image publication waits briefly when another publication is using the same transport, instead of failing immediately.
If a stateless revision fails its readiness check, recovery waits for a fresh admission check before restoring the previous revision. The original readiness failure remains in the operation history.
Stop requests and revoked permissions still take precedence. This does not roll back database changes or persistent application data.
Enrolled Drone command pipelines can use more parallel steps and report completed dependencies sooner, within their project resource allowance.
Workers now recognize equivalent Kubernetes CPU and memory units when checking their installed allocation. Stop and replacement still require confirmed process termination.
LISTEN's registered pipeline runs tests and image builds concurrently. Tests and deployment gates remain in place; cold downloads and dependency changes can still take longer.
Fixed a browser form setting that could reject the confirmation after signing in to Pangea.
Registered apps can finish sign-in after you confirm profile sharing. Origin and CSRF checks remain enforced, and referrer information is not sent to other sites.
Registered apps can use the existing Pangea sign-in. App developers do not need a separate Google OAuth registration.
Creating an account does not allocate a hosting workspace or start any charges. Hosting applications and app subscriptions remain separate.
The initial app-login pilot is operator-registered. Apps receive an app-specific user ID and a consented profile, never workspace or operator permissions. Each app controls its own access and billing.
The command runtime now supports operator-bound credential files restricted to enrolled push branches. Existing jobs receive no additional credentials.
This is preparation only: registry publishing, deployment permissions and repository activation are not enabled by this change.
Project and credential context checks run before a Job starts. Bound values are filtered from the CI log, and their temporary Secret is removed with the Job.
Cluster services now show status and CPU and memory meters in compact rows. Open a row to inspect individual containers, restart counts, running time and images.
Rows total the running containers in the current node selection. Totals with missing or stale readings remain unknown. Keyboard and mobile users can open the same details.
Authorized cluster viewers can see container states, restart counts, running time, and CPU and memory meters inside the service list.
Selecting a node scopes the container details to that node. Active Jobs and standalone Pods are included alongside services.
CPU is a five-minute average. Meters use the container limit, or explicitly show node capacity when no limit is set. Missing readings remain unknown. This view covers Kubernetes containers and keeps the existing viewer access restrictions.
An opt-in connection streams enrolled command output back to Drone, so test progress and failures can be inspected alongside the build result.
Output stays within the owning project's read permissions and remains available after the execution Pod is cleaned up. Collection and storage limits are shown explicitly.
This requires administrator activation for each trusted command profile and client. Artifact uploads and screenshot links are not included; the CI migration remains a trial.
External CI systems can submit administrator-enrolled commands through the project Jobs API, sharing resource reservations with existing CI jobs.
Command profiles fix the repository, branch, source entrypoints, resources and execution deadline. Source checkout uses a repository-only read credential rather than GitHub Actions registration.
Job success requires the process to succeed and its owned resources to be cleaned up. Uncertain launches keep their original identity instead of starting a duplicate.
The Drone connection requires separate administrator activation. Rabbit remains a trial; this update does not announce a completed migration or enable arbitrary commands for all projects.
Registered Docker-enabled CI jobs keep their default nested containers and BuildKit processes inside the job's CPU and memory limits.
The Docker service verifies its allocated limits before starting and fails closed if it cannot establish the bounded hierarchy. This protects running apps from accidental CI resource exhaustion; privileged Docker execution remains restricted to trusted code.
Nested Docker networks inherit the job Pod’s network MTU, avoiding stalled dependency downloads on overlay networks without expanding network access.
Reviewed CI profiles can select a branch and trusted maintainers, allow manual trial runs at the current branch tip, and reserve up to six hours per job. Existing profiles keep their previous admission policy and limits. This does not enable arbitrary repository enrollment or claim that Rabbit CI migration is complete.
Applications safely stopped by a confirmed runtime hazard can now restart with their existing image after the platform has remained healthy for 60 seconds.
Recovery checks current access, available resources, unchanged application configuration and confirmed termination of previous Pods. It does not rebuild the app or roll back its data.
Expired or revoked access, cancelled apps, older stop records and uncertain deployments remain stopped for review. Database failover still requires the existing single-writer safeguards.
The legacy host Docker CI runner that bypassed the shared execution limits has been retired. Customer applications remain on the existing resource-managed cluster.
Cluster nodes give applications time to stop before shutting down their storage and networking. Databases retain a single writer and their replicated data.
Normal node reboots use Kubernetes graceful shutdown. Applications can restart after storage is released and readiness succeeds; database recovery has no one-minute deadline.
A returning node rejoins through its existing agent and storage reconciliation. Deliberate administrator cordons remain in place until maintenance is complete.
Unreachable nodes are not assumed to be powered off. Timeout-based forced storage detachment is disabled; permanent node failure still requires a verified stop before moving a database. Independent power fencing is not yet available.
Registered CI workers preserve private credential permissions when the node agent remounts their storage, avoiding an interruption to CI dispatch after an agent restart.
The enrolled compute pool now has six nodes. Rolling apps without a local persistent disk use a shorter wait before Kubernetes replaces a Pod on an unavailable node.
After Kubernetes detects NotReady or Unreachable, these apps wait 10 seconds instead of the default five minutes before eviction. Image download, startup, readiness and database availability still affect total recovery time; a one-minute recovery is a target, not a guarantee.
The shorter wait applies on the next deployment of a configured stateless rolling app. Persistent apps, databases and management state retain their existing single-writer recovery protections.
Existing apps and databases stayed running while the two nodes joined. Their automatic agent restart and sandbox execution were verified; this does not claim a full production power-failure test or complete management redundancy.
Pangea's registered GitHub integration worker now runs on the shared Kubernetes pool through the project worker API. Its credentials stay on replicated storage, and customer apps were left running during the switch.
The worker can be placed on any of the four enrolled nodes. Controlled replacement waits for the previous process to stop, avoiding duplicate CI dispatch.
The execution provider and some renewal services still depend on one host. This is a step toward redundancy, not automatic recovery from every node or network failure.
This applies to the installed Pangea CI integration. Self-service registration of arbitrary CI workers is not yet available.
The production management API can now move between enrolled cluster nodes while retaining its existing data. A controlled move completed with customer apps and databases left running.
Management operations briefly pause during a controlled move. The API keeps one active writer; this is not active-active management or automatic failover during a network partition.
CI coordination and some maintenance services still depend on a separate host. Removing those remaining dependencies is a later stage.
For enabled production workspaces, unavailable management observations or a pending configuration review block new deployments without automatically stopping existing apps.
Explicit suspension, expired or revoked access, and confirmed isolation or storage hazards still stop affected execution. Recovery never restarts a stopped app without an authorized deployment.
This improves app continuity during management changes; it does not make the management service or databases highly available.
App CPU meters use a five-minute average to accommodate variable collection intervals. Stale or unavailable measurements remain unknown, not zero.
Configured CI projects use disposable Kubernetes jobs through the shared execution API. Jobs can run concurrently on available enrolled nodes, within shared resource limits.
Pangea's own checks use the same registered workflow profiles and project job API. Docker-enabled profiles remain restricted to trusted enrolled repositories.
App resource meters include Kubernetes web and database workloads. Missing measurements remain unknown rather than showing zero usage.
Reviewed placement-only network-agent changes can retain existing healthy agents; changing their executable configuration still requires a matching review. This does not remove deployment or infrastructure failure risks.
App cards show a compact traffic chart and actual resource usage meters. CI cards use a clearer gear-and-play icon and show recent job results and durations.
See hourly requests, errors, response time, and web + database resources from existing observations. Missing data stays unknown.
Authorized cluster viewers can open Cluster from Your apps using their existing sign-in. Access is read-only and explicitly granted; ordinary customer accounts cannot see cluster-wide data.
Migrated apps use app-name.pangea.host. Opening a page at the previous app-name.apps.pangea.host address redirects to the new address, keeping the path and query string.
New address names must be 6–40 characters. Names of five characters or fewer and platform-reserved names cannot be claimed. Existing reservations are preserved.
Address setup remains operator-assisted. App ownership, data and the original project-ID address stay unchanged.
Tabs already open at the previous address can continue their API calls and uploads there; the redirect applies to page navigation.
An app may ask you to sign in again at its new address. Apps with a fixed external address or OAuth callback need that configuration checked before migration.
The expanded shared beta plan lets enabled workspaces create multiple apps within one resource allowance, without a separate app-count cap.
The shared beta allowance is 2 vCPU, 4 GiB of memory, 10 GiB of allocated storage and 300 build minutes per UTC month. Your console shows the plan enabled for your workspace.
Your AI can allocate resources between apps. CPU and memory are shared reservation limits; persistent storage remains allocated when an app is stopped.
The deployment registry now has a configurable platform capacity budget, replacing its initial eight-app ceiling. Workspace resource limits and per-app access checks still apply.
Existing connections and complimentary expiry dates are preserved when an invitation is upgraded. No payment or automatic charge is added.
CI projects still require operator setup. Shared self-service app creation does not grant access to an internal CI runner.
Your apps now has compact visual status cards. Open an app to see its components, reserved resources and recent traffic. Configured CI projects show recent runs and task activity.
Traffic charts are compact by default, with soft area fills and an expanded view when you need more detail.
Choose 1h, 3h, 6h, 12h, 24h, 2d, 3d or 7d. Inspect an interval directly on the chart with a pointer, touch or keyboard.
See estimated request counts, server error rates and mean response times. Missing observations stay visible as gaps; they are never shown as zero traffic.
CI cards distinguish running, queued, completed and failed work. Resource reservations are shown separately from measured activity.
Enabled apps can use a memorable name under apps.pangea.host. Ask your coding agent to configure an available name using the app's existing connection.
Addresses belong to a specific app and are checked for availability. Existing app data and ownership stay with the same app.
Your console shows the verified public address when the app is ready.
Pangea is in invited beta. CI execution is available to configured projects; self-service CI registration is not yet open. Open your apps →
