Defining resources

A resource is one internal app or one host a vendor is allowed to reach. Nothing is reachable until it is defined here, and defining it is the whole per-app setup: no DNS record, no certificate, no change on the connector.

Resources live under Infrastructure → Resources. Every resource is served through a connector, so install one first.

Three access methods

The access method is chosen on the resource form and decides what reaches the vendor's screen. All three pass the same sign-in and grant checks; they differ only in the tail.

Method	What the vendor gets	Use it for
TRANSPARENT	The web app itself, proxied into the vendor's own browser. WebSocket traffic passes through, so streaming consoles work.	Internal web apps: ticketing, wikis, management UIs.
GATEWAY	A live RDP, SSH or VNC screen rendered in the browser by the session engine (guacd) running on the connector host.	Servers and workstations, no client to install.
ISOLATED	Only pixels. The app opens in a throwaway server-side browser (KasmVNC) on the connector host; no page content, cookie or file reaches the vendor's machine.	The most sensitive apps; strongest isolation.

The public hostname

Each resource has a public address the vendor types into a browser. You enter only a label; the suffix is fixed by the deployment and appended for you.

Cloud: wiki becomes wiki.<your-org>.cloud.captivo.io.
Your own server: wiki becomes wiki.<access-domain>, for example wiki.access.acme.com.

There is nothing to do in DNS or for certificates per app: the wildcard record you created at install time already covers every label, and the certificate is issued automatically the first time a browser opens the address.

A TRANSPARENT resource can use your own domain instead, such as portal.acme.com: switch Domain type, enter the full name, point that name's A record at the server, then press Verify. On Cloud the certificate is issued for you once verification passes; on your own server the bundled Caddy issues it on first visit.

1Add a web app

Open Infrastructure → Resources → Add resource, choose the Web app (TRANSPARENT) method and fill in:

Name: what admins and vendors see, e.g. Internal Wiki.
Hostname: the label described above.
Internal address: the address the connector reaches, e.g. http://10.0.5.20:8080. It is never shown to the vendor and never resolved from the internet. This is the field most often filled in wrongly: it is not what works from your laptop, it is what works from the machine the connector runs on.
Connector: the connector that can reach that address.

Save. The first visit to the public hostname provisions its certificate; from then on the app is reachable by anyone who holds a grant for it.

2Add a remote desktop (RDP/SSH/VNC)

Choose the Remote desktop (GATEWAY) method. Besides the name, hostname and connector you give the target's protocol, host and port, and the username and secret the session should sign in with.

The credential is stored encrypted in the built-in vault and injected into the session on the server side. The vendor never sees the password and cannot copy it out: what they get is a live screen, not a login prompt.

For RDP you can also pick the security mode (NLA, TLS, RDP) to match the target's setting; a mismatch is the usual reason a session fails to connect even though the credential is right. See the remote desktop session does not connect.

3Add an isolated browser

Choose the Isolated browser (ISOLATED) method and give the internal URL the throwaway browser should open. Because the browser runs on the connector host and the vendor only receives pixels, this method unlocks controls the other two cannot enforce:

Clipboard direction: allow, block copy-out, block paste-in or both, enforced on the server.
Screen watermark: the vendor's e-mail and a live clock composited onto the screen, so a screenshot carries its author.
File transfer, per direction (upload into the browser, download out), off by default. Transfers are wiped when the session ends and every one is written to the audit log.

Per-resource settings: recording, clipboard, file transfer

Record sessions: web apps are captured by an injected DOM recorder, remote desktops from the session engine's stream, isolated browsers as a seekable video. All of it is written to the connector's own disk, not to the control plane; see session recording and live view. If Policy sets the recording mode to Required, this toggle is forced on.
Clipboard on a web app: block copy-out, paste-in or both. The proxy injects a guard into the app's pages, so this is a deterrent rather than a hard control; a vendor with JavaScript disabled can get around it. Remote desktops use the session engine's own clipboard settings instead, and the isolated browser enforces its rule on the server.
File transfer on a remote desktop: SFTP for SSH, a mapped drive for RDP. Default inherits the value from Policy, and Policy's own Default is the engine default, which is off. A file dropped onto a session with transfer off goes nowhere. SSH uploads land in the login user's home directory unless you set SFTP upload folder.
Engine options: RDP sound and printing (prints arrive as a PDF download), SSH terminal font size, colour scheme and scrollback.

Health checks

Every five minutes a probe opens a TCP connection to each resource's internal address through its connector. Infrastructure → Resources shows the result as Reachable or Unreachable with the measured latency, and the dashboard summarises it.

When a resource goes down or recovers, a notification is raised in the console bell and, if a webhook URL is set in Policy, posted there too. A resource marked Unreachable is the first thing to look at when a vendor reports a 502; see the app does not open.

For product-wide problems: The connector shows offline · The app does not open · Cannot sign in with a passkey