Links

A link is a subdomain your license carries, with a TLS certificate already issued for it. The engine binds one to a running workflow step and serves that step's port over HTTPS — so a container on your machine is reachable from a browser anywhere, with no tunnel, no port forwarding, and no certificate of your own.

What your license carries

{
  "link": { "name": "dakumori", "count": 4 }
}

The name is drawn by the platform and belongs to the engine. The root answers for the engine itself — its API and console — and the sub-labels count opens are the pool your workflows publish on:

   dakumori.link.dxflow.ai     the engine    API, console
   a.dakumori.link.dxflow.ai   free          claimable by a workflow step
   b.dakumori.link.dxflow.ai   free          claimable by a workflow step
   c.dakumori.link.dxflow.ai   free          claimable by a workflow step
   d.dakumori.link.dxflow.ai   free          claimable by a workflow step

Sub-labels always run from a, so count decides how much of the range the engine offers.

Getting them

dxflow login              # once per engine
dxflow license activate   # license, certificates, address

Activation stores a certificate and key for every link in the engine directory, and registers the address the platform observes — which stays correct behind NAT, where an engine sees only its private interfaces.

Certificates issued after activation are collected by running dxflow license activate again; the command names any link still awaiting issuance. Nothing renews behind you: chains and license run out together at 90 days, and a fresh license draws a fresh name.

Publishing a step

A step names the port it publishes, beside the ports it declares:

name: desktop
steps:
  - name: app
    image: dxflow/desktop
    ports:
      - name: web
        host: 6080
      - name: vnc
        host: 5901
    link: web

dxflow workflow start desktop

That is all of it. Every start claims a link for each step naming a port, and the start prints what it published:

✔ desktop started
  app.web    https://a.dakumori.link.dxflow.ai  →  6080

link names one port, and that port answers at the root of the link — no path prefix, so an image serves exactly as it does on a host port. A step that needs a second port on the internet is a second step, which draws its own link.

The name must be a port the step declares; the engine checks it when the workflow is created, so a typo fails there rather than at the first start.

Claiming follows the workflow

Starting claims a link and stopping releases it, so holding one is the same thing as running.

A stopped step keeps the name it held and takes it back on the next start when it is still free, so a stop and start returns the same URL and a bookmark survives. If something else claimed it meanwhile, the step gets another free one. When every link is claimed the workflow still runs, with the step unpublished and the reason on its events — the compute is the job, and the link is how you reach it.

Claiming is local to the engine, so a workflow starts at the same speed with the platform unreachable. An engine whose license carries no link runs the workflow unpublished.

Passing a link to a container

A container cannot infer a name it was assigned. Links reach it through the environment the workflow already declares, in workflow.ini:

[env]
app.API_URL = {{ link.api }}

{{ link.<step> }} resolves to the address that step publishes. Any step can name any step's link, so a frontend finds an API running beside it. A placeholder for a step holding no link resolves empty, which leaves your image on its own fallback and keeps it working unpublished.

Naming a link never publishes one — the step's own link key is the only thing that does, so editing [env] cannot put a port on the internet by accident.

Serving

Links ride the engine's own listeners, so --https serves them on the same socket as the API and console. The certificate is chosen during the TLS handshake, before any HTTP is read, so the engine knows which step to forward to ahead of the request.

--http serves the same routing by Host, which suits an engine behind a TLS terminator: the proxy in front answers the certificate and forwards on. The engine sets X-Forwarded-Host and X-Forwarded-Proto for the container behind it.

Seeing what is published

dxflow workflow list             # a link column
dxflow workflow steps desktop    # the link each step holds
dxflow license info              # the root and pool size

Limits