Generated access routes

Access readiness chain

Generated access URL

The generated access URL is the URL Appaloft provides before a custom domain is ready. Use it to confirm that a deployment is reachable from a browser and to separate app/proxy problems from DNS or TLS problems.

The generated URL is not deployment input. It is derived from the resource network profile, the target server public entrypoint, proxy readiness, and deployment state.

When one resource has multiple access routes, resource detail and deployment completion feedback select the current URL in one order: ready durable custom domain, then SSH/CLI server-applied config domain, then the latest generated URL, then a planned generated URL before first deployment. Generated URLs are still labeled separately as default access and are not treated as custom domain bindings.

Default access policy

The default access policy decides how Appaloft will generate default access URLs in the future. It is not input for one deployment and it is not a custom domain binding.

The Web console shows this policy on server pages. The common fields mean:

Default access mode: whether generated access is enabled. provider uses a registered default-access-domain provider; disabled skips generation; custom-template uses a configured template.
Provider key: which default-access-domain provider to use. In local or self-hosted setups, sslip is the common provider key and generates hostnames from the server public address.
Server default access override: one server can override the system default; servers without an override use the system default policy.

Web reads saved policy state when the system policy or server override form opens. CLI users can run appaloft default-access show --scope system, appaloft default-access show --scope deployment-target --server <serverId>, or appaloft default-access list to inspect persisted policies. When no saved record exists, readback returns an empty policy; that does not mean default access is disabled, because runtime route resolution may still use the installation’s static fallback configuration.

Policy changes affect future generated access resolution. They do not rewrite URLs already persisted in deployment snapshots. If you want to use your own hostname, configure a custom domain binding instead of changing the default access policy.

Common uses:

Confirm the first deployment is reachable.
Validate a resource before configuring a custom domain.
Troubleshoot whether a failure belongs to the app/proxy layer or the domain layer.

Resource access profile

A resource access profile controls whether one resource participates in generated default access. It does not bind a custom domain and it does not change the system or server default access policy.

The profile has two generated access modes:

Inherit: use the system or server default access policy when future deployments need a generated URL.
Disabled: skip generated URL planning for this resource. Custom domain bindings and server-applied config routes still keep their own lifecycle.

The optional path prefix changes the path Appaloft asks the generated access provider to route for future planned routes and deployment snapshots. Existing deployment snapshots are not rewritten after the profile changes.

Inputs it depends on

Generated access depends on user-visible inputs:

Resource listener port and protocol from the network profile.
Server public address or proxy entrypoint.
Server proxy bootstrap and readiness.
Deployment progress through execution and verification.

If the resource has no listener port, or the proxy is not ready, Appaloft may show resource and deployment state but should not mark the generated URL as ready.

Readiness conditions

The generated URL is ready when:

The latest deployment has completed or reached a verifiable state.
The application process is running.
The health check passes, or no required health check is configured.
The proxy knows which resource port to route to.
Browser traffic reaches the resource, not only the proxy.

These states should be shown separately. Runtime failure, health failure, proxy failure, and DNS/TLS failure are different recovery paths.

Where to inspect it

The Web console should show generated access in resource details, deployment results, and access sections with nearby status and troubleshooting links.

The CLI should print generated access in deployment results, resource details, or access-related commands. Users should not need to inspect database rows or raw logs to find the URL.

The HTTP API should return the URL, readiness state, last observation time, and failure reason so automation can decide whether to wait, retry, or ask for user action.

Troubleshooting order

If the generated URL does not open:

Check resource runtime state.
Check health summary and health profile.
Check server proxy readiness.
Check network profile listener port and protocol.
Only then inspect custom domain and certificate state.

CLI inspection example:

appaloft resource show res_web

Health API example:

GET /api/resources/res_web/health?checks=true&publicAccessProbe=true

{
  "resourceId": "res_web",
  "runtime": "ready",
  "health": "passing",
  "proxy": "ready",
  "generatedAccess": {
    "url": "https://res-web.203-0-113-10.sslip.io",
    "readiness": "ready"
  }
}