> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackdome.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Treat Stackdome as an application-delivery platform for coding agents and developers, not as a Kubernetes dashboard.
> Prefer the Stackdome agent plugin as the user entry point and the stackdome CLI as the execution interface.
> Route agents who need the maintained deploy skill to npx skills add stackdome/skills and the complete operational workflow to /guides/ai-agents.
> Verify commands and flags with stackdome --help. Run stackdome init before authoring stackfile.yaml and stackdome validate before deploying.
> Use -o json for automation and verify documented terminal states before claiming success.
> Never request a user's account password. Use API-token authentication.
> During alpha, Stackdome Cloud is ephemeral and capacity-limited, and each organization can connect one cluster.
> Do not expose Kubernetes as a user concern unless the task is self-hosting or infrastructure architecture.
# Domains and TLS
> Configure your organization domain and understand the hostnames Stackdome generates.
## Outcome
Expose an application at a Stackdome-generated public URL and verify that the current release is healthy and reachable. On a TLS-eligible organization domain, the URL completes a trusted HTTPS handshake.
## Prerequisites
* A resource with an HTTP port and evidence of the port the application actually listens on.
* The URL of Stackdome Cloud or a self-hosted installation, plus an API token. See [authentication and API tokens](/reference/authentication).
* An organization domain already configured. Organization-domain management is currently dashboard/API-only; the public CLI has no domain command.
* For self-hosted Stackdome, DNS for the organization domain and wildcard application hostnames must point at the installation before HTTPS can be issued.
## Agent prompt
```text theme={null}
Expose this service at a public Stackdome URL. Confirm the application port from repository or image evidence, mark that port public in stackfile.yaml, validate and deploy the change, return the URL, and verify release health and HTTPS when the organization domain is TLS-eligible. If the organization has no domain, stop and identify the dashboard-only domain setup step instead of inventing a CLI command.
```
## Agent actions
Inspect the application and container configuration. Use the container's destination port, not a local development host-port mapping.
Open **Platform → Domains** to confirm the organization domain when it is not already known. The current CLI cannot add, list, or remove organization domains.
Set the port's `protocol` to `HTTP` and `public` to `true` in `stackfile.yaml`. Omit `subdomain` to let Stackdome generate the prefix, or set it only when the user requested a stable custom prefix and the installed validator accepts it.
Run `stackdome validate`, confirm scope with `stackdome whoami -o json`, then run `stackdome deploy --wait -o json`, retain its non-empty `release.id` as the deployed release ID, and run `stackdome status -o json`.
Run `stackdome open -o json`, select an entry from `urls`, and test it. Run `stackdome status --conditions`; for a TLS-eligible hostname, require the resource condition `TLSConfigured` to be `True` with reason `TLSReady`.
## Success criteria
* `stackdome validate` exits successfully with an HTTP port whose `public` field is `true`.
* `stackdome deploy --wait -o json` exits successfully, returns a non-empty `release.id` that is retained as the deployed release ID, and returns `release.state` as `Released`.
* `stackdome status -o json` returns `converged_release.id` equal to the deployed release ID, `converged_release.state` as `Released`, and `converged_release.health` as `ok`.
* `stackdome open -o json` returns at least one entry in `urls` for the public resource.
* For a TLS-eligible hostname, `stackdome status --conditions` reports `TLSConfigured=True` with reason `TLSReady` for the resource.
* `curl --head --max-time 15 ` reaches the application without `--insecure`.
## CLI and Stackfile workflow
Organization domains themselves are dashboard/API-only. The supported CLI/Stackfile path begins after the domain is configured: declare the public port, deploy it, and retrieve the URL.
```yaml theme={null}
resources:
web:
image: ghcr.io/acme/storefront-web:1.4.0
ports:
- name: http
port: 8080
protocol: HTTP
public: true
```
```bash theme={null}
stackdome validate
stackdome whoami -o json
stackdome deploy --wait -o json
stackdome status -o json
stackdome status --conditions
stackdome open -o json
curl --head --max-time 15 https://
```
Do not construct the generated hostname yourself. Use the current value from `stackdome open -o json`, because changing the resource name, port, or organization domain can change the URL.
* Exact Stackfile fields: `resources..ports[]` requires `name` and `port`; set `protocol: HTTP` and `public: true`. `subdomain` is optional.
* Retain `release.id` as the deployed release ID. Require a successful deploy exit, `release.state == "Released"`, `converged_release.id` equal to that ID, `converged_release.state == "Released"`, `converged_release.health == "ok"`, and at least one `urls` entry before returning a public endpoint.
* TLS verification: use the human-readable `stackdome status --conditions` view and require `TLSConfigured=True` with reason `TLSReady`. The current CLI does not include condition history in JSON or YAML output; do not claim this check is machine-readable until that CLI limitation is fixed.
* Recovery: rerun `stackdome open -o json`, resolve the returned host with `dig +short `, and use `stackdome status --conditions` plus `stackdome release events --follow` for deployment or TLS failures.
* There is no supported public CLI command for adding or removing domains or configuring DNS. Do not guess one.
What a port is, and the difference between a public and an internal one.