App access and service URLs

Choose an access policy

Declare access in atrium.yaml. Rules refer to service keys from your services block and match request paths and, optionally, HTTP methods. The default is subscription when no policy is supplied.

protected is a compatibility alias for subscription rules. Prefer subscription in new manifests. Publishing an app or belonging to its owning workspace does not bypass a subscription rule. Even a Free plan requires explicit enrollment; a zero price is not anonymous access.

This example assumes services named frontend, backend, and gql:

access:
  default: subscription
  public:
    - service: frontend
      paths: ["/", "/_next/**", "/favicon.ico", "/api/health"]
      methods: [GET, HEAD]
    - service: backend
      paths: ["/health"]
      methods: [GET, HEAD]
  developer:
    - service: gql
      paths: ["/console/**"]
  subscription:
    - service: frontend
      paths: ["/app/**", "/api/cases/**"]
    - service: gql
      paths: ["/v1/graphql"]

Add your actual static asset paths to the public rules. Keep API routes protected unless they are intentionally public. An app's data authorization remains necessary after a gateway check succeeds.

Matching and precedence

• /app matches that exact path; include /app/ separately if both must match.
• /app/* matches one path segment below /app/.
• /app/** matches /app and its descendants. /** matches every path.
• Wildcards are supported only at the end as /* or /**.
• Omit methods to match all supported methods. Otherwise use uppercase names such as GET or POST.

When rules overlap, precedence is: migration, deployment, developer, subscription, protected, public. The default applies only if no rule matches. This is not a most-specific-path or first-written-rule policy. For example, a public /app/help does not override a matching subscription /app/** rule.

Hasura console and administration routes have additional access requirements. See Databases and migrations before exposing a Hasura service.

Use the returned service URL

Canonical service URLs have this shape:

https://<service>.<agent-slug>.apps.atrium.st

For example, a service named gql in my-agent uses https://gql.my-agent.apps.atrium.st. The service key determines the hostname; type: hasura does not force the name database. Use the URL returned by atrium status for service integrations and the app's returned home URL for launch. Existing compatibility aliases may continue working, but new integrations should use canonical URLs.

App domains such as my-agent.atrium.st and approved custom domains can provide a visitor-facing URL. A manifest domain declaration alone does not complete domain approval, DNS, or TLS setup. Arrange that setup with Atrium before switching traffic, and verify the returned URL after a successful deployment. Do not build integrations against private service origins or request direct cloud access.

Handle denied access

Browser navigation can redirect to sign-in or the app's pricing page. API requests receive an error instead; handle it as an authorization result rather than attempting to parse an HTML login page as JSON.

For an installed app that redirects to pricing, first confirm the selected workspace. An installation in another workspace does not grant this workspace access. Preserve the validated return destination through sign-in and plan selection; do not treat a checkout return URL as proof of payment.

The gateway supports streaming responses and WebSocket connections, subject to the same route policy. Use authenticated application context for user/workspace checks. Never accept caller-supplied identity headers as proof of authorization on an independently exposed endpoint.

Continue with workspace installations or billing and entitlements.