Workflow Endpoints

When a workflow service exposes network endpoints (configured via the network section in your workflow definition), the fuzzball workflow endpoints command retrieves the public URL(s) for those endpoints.

Usage


$ fuzzball workflow endpoints WORKFLOW_ID [SERVICE_NAME] [ENDPOINT_NAME]

Arguments:

Argument	Required	Description
`WORKFLOW_ID`	Yes	The ID of a running workflow
`SERVICE_NAME`	No	Filter results to a specific service
`ENDPOINT_NAME`	No	Filter results to a specific endpoint within a service

Examples

Get all endpoints for a workflow:


$ fuzzball workflow endpoints <workflow_id>

SERVICE       ENDPOINT   URL
jupyter       web        https://endpoints.example.com/endpoints/accounts/.../jupyter/web/
api-server    grpc       https://endpoints.example.com/endpoints/accounts/.../api-server/grpc/

Get all endpoints for a specific service:


$ fuzzball workflow endpoints <workflow_id> jupyter

Get a specific endpoint by name:


$ fuzzball workflow endpoints <workflow_id> jupyter web

Output the results as JSON (useful for scripting):


$ fuzzball workflow endpoints <workflow_id> -o json

Configuring endpoints in a workflow

Endpoints are declared in the network section of a service definition. For example, a Jupyter service that exposes a web endpoint:


services:
  jupyter:
    image:
      uri: docker://jupyter/base-notebook:latest
    script: |
      #!/bin/bash
      jupyter lab --ip=0.0.0.0 --no-browser
    resource:
      cpu:
        cores: 2
      memory:
        size: 4GB
    network:
      ports:
        - name: web
          port: 8888
          protocol: tcp
      endpoints:
        - name: web
          port-name: web
          protocol: https
          type: path
          scope: user

See the workflow syntax reference for full details on the network configuration options.

Environment variables for endpoints

When a workflow service runs, Fuzzball automatically injects environment variables for each configured endpoint. These variables allow your service code to discover the public URLs assigned to its endpoints.

For each endpoint, two environment variables are provided:

FB_ENDPOINT_PATH_<ENDPOINT_NAME> — the full URL path to the endpoint
FB_ENDPOINT_URL_<ENDPOINT_NAME> — the complete URL including protocol and host

Environment variable naming

The <ENDPOINT_NAME> suffix is derived from the endpoint's name field by:

Converting the name to uppercase
Replacing any character that is not a letter, digit, or underscore with an underscore (_)

This transformation ensures that the generated environment variable names are valid POSIX shell identifiers and compatible with all container runtimes.

Examples:

Endpoint name	Environment variables
`web`	`FB_ENDPOINT_PATH_WEB` `FB_ENDPOINT_URL_WEB`
`jupyter-one`	`FB_ENDPOINT_PATH_JUPYTER_ONE` `FB_ENDPOINT_URL_JUPYTER_ONE`
`my.endpoint`	`FB_ENDPOINT_PATH_MY_ENDPOINT` `FB_ENDPOINT_URL_MY_ENDPOINT`
`api_v2`	`FB_ENDPOINT_PATH_API_V2` `FB_ENDPOINT_URL_API_V2`

Note

Simple alphanumeric endpoint names (containing only letters, digits, and underscores) are unaffected by this transformation beyond being converted to uppercase.

Using endpoint variables in startup scripts

You can reference these environment variables in your service's startup script to configure applications dynamically:


services:
  web-app:
    image:
      uri: docker://myapp:latest
    script: |
      #!/bin/bash
      echo "Service available at: $FB_ENDPOINT_URL_WEB"
      ./myapp --public-url="$FB_ENDPOINT_URL_WEB"
    network:
      ports:
        - name: http
          port: 8080
          protocol: tcp
      endpoints:
        - name: web
          port-name: http
          protocol: https
          type: path
          scope: user

For an endpoint named jupyter-notebook, you would reference the sanitized variable names:


echo "Notebook URL: $FB_ENDPOINT_URL_JUPYTER_NOTEBOOK"

Job Hostnames Connecting to Workflow Services