Skip to main content
An HTTPS link serves one port of an instance at its own address, with a valid certificate:
Use it for a web app, a notebook or an API listening over plain HTTP on that port. You can share it or call it from code without setting up a domain or a certificate. When you add a link you pick who can open it: You can change who can open a link at any time; the change applies within seconds. A workspace link is opened through the dashboard’s Open button, which hands your browser an entry address that works once, within two minutes, for you alone. It signs you in to the link for 12 hours in that browser; after that, open it from the dashboard again. Removing someone from the workspace signs them out of every workspace link within two minutes. Copying a workspace link copies its plain address: a member who follows it is told to open it from the dashboard. The sign-in cookie stays with Runcrate’s proxy: your app never receives it. Other sites can’t show a workspace link in a frame (your app can still frame its own pages), and other pages can’t send requests to it with your sign-in; open it as its own page.

​
The rules

  • Links belong to the instance, not to its environment’s firewall. A link needs no firewall rule: its port is opened to Runcrate’s proxy only. Other visitors reach the port directly, on the instance’s address and without the link’s check, only if a firewall rule opens it to them. The link shows a warning when one does, or when the instance’s firewall isn’t enforced.
  • One link a port, up to 10 links an instance. SSH (port 22) and Runcrate’s own ports (7681, 10010, 10011) can’t have one.
  • Your app must listen on all interfaces (0.0.0.0), not only 127.0.0.1.
  • Workspace owners and admins, and whoever launched the instance, can add, change and remove links. Every member can see and open them.
  • Links work while the instance runs and end with it.
  • Instances started before the firewall existed can’t have links: start a new instance to use them.
All links share the runcrate.app domain, so browsers treat pages on different links as the same site. Give apps with their own sign-in a cookie name of their own and don’t rely on cookies being private to one link. HTTPS covers the connection from the visitor to Runcrate’s edge. From there to your instance the request travels as plain HTTP over the internet, to the port your app listens on. For data that must stay encrypted all the way, serve TLS from your app and connect to the instance’s port directly.
Connect the Runcrate MCP server, then ask in plain words:
The agent calls create_instance_link with port: 8080 and access: "public", and answers with the link’s url. See MCP tools.