OGC API Processes — Dashboard

Dashboard

Processes

—

Total jobs

—

Running

—

Successful

—

Failed

—

Callbacks

Recent jobs

Job ID	Process	Status	Created
—

Activity log

Connecting…

Deploy process

DRU — Part 2

Process identity

Process ID *

Title

Description

Execution unit (Docker)

Docker image *

Image digest (sha256) * security

Network mode security

Use bridge only if the process image needs outbound network access (e.g. fetching from a SensorThings API). none is the secure default.

Process description (JSON — OGC schema)

Inputs schema

Outputs schema

📦 How to create a deployable Docker image ▼ show

Any Docker image can be deployed as an OGC process as long as it follows the stdin → stdout I/O contract below.

I/O contract

Stream	Direction	Content
stdin	← server writes	JSON object of process inputs, closed with EOF when done
stdout	→ server reads	JSON object of process outputs — streamed directly to IPFS
stderr	→ server logs	Diagnostic messages — visible in worker logs, never stored

Exit codes

0	Success — stdout content is uploaded to IPFS
≠ 0	Failure — job marked failed, stderr tail included in error

Input JSON structure (stdin)

{ "fieldName1": "string value", "fieldName2": 42, "fieldName3": true }

Field names match the keys in the Inputs schema below. The server writes the execution request's inputs object to stdin and closes it with EOF.

Output JSON structure (stdout)

{ "outputField1": "result value", "outputField2": { "nested": "object" } }

Any valid JSON. The entire stdout is stored verbatim on IPFS. Field names should match the Outputs schema below.

Minimal Node.js example (index.js)

process.stdin.resume();
const chunks = [];
process.stdin.on('data', c => chunks.push(c));
process.stdin.on('end',  () => {
  const inputs = JSON.parse(Buffer.concat(chunks).toString());
  // ... process inputs ...
  process.stdout.write(JSON.stringify({ result: inputs }));
  process.exit(0);
});

Minimal Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY . .
USER node
CMD ["node", "index.js"]

Build, test & get the digest

# Build
docker build -t docker.io/myorg/myprocess:1.0 .

# Test locally
echo '{"fieldName":"value"}' | docker run --rm -i docker.io/myorg/myprocess:1.0

# Push
docker push docker.io/myorg/myprocess:1.0

# Get sha256 digest for the Image digest field
docker inspect --format='{{index .RepoDigests 0}}' docker.io/myorg/myprocess:1.0
# → docker.io/myorg/myprocess@sha256:abc...  (copy the sha256:... part)

Execute process

POST /processes/{id}/execution

Target

Process ID *

Execution mode

Inputs (JSON)

Callback subscriber (optional)

Success URI — the dashboard listens on this simulated endpoint

In a real deployment the server POSTs the job result to this URI. The dashboard simulates callback reception via polling.

Execute access required. Your account does not have the ogcapi:execute privilege. Ask an admin to grant it.

Process list

My processes 0

ID	Title	Version	Image	Deployed	Actions
No processes deployed by you

Other users' processes 0

ID	Title	Version	Image	Owner	Deployed	Actions
No processes from other users

Job monitor

Auto-refresh (5s)

Job ID	Process	Status	Created	IPFS CID	Actions
No jobs yet

Job callbacks

When a job completes the server notifies the subscriber URI. The dashboard simulates receiving these callbacks by polling active jobs. Each notification appears here and as a toast.

No callbacks received yet

API Documentation

OpenAPI 3.0

OpenAPI specification

The server exposes a full OpenAPI 3.0 description at …/api/1.0/openapi. Open the interactive Swagger UI in a new tab or download the raw JSON.

Endpoints

Method	Path	Scope	Description
GET	/	—	Landing page
GET	/conformance	—	Conformance classes
GET	/api/1.0/openapi	—	OpenAPI 3.0 spec
GET	/api/1.0/processes	public	List processes
GET	/api/1.0/processes/{id}	public	Process description
POST	/api/1.0/processes	ogcapi:deploy	Deploy process (DRU)
PUT	/api/1.0/processes/{id}	ogcapi:deploy	Replace process (DRU)
DELETE	/api/1.0/processes/{id}	ogcapi:deploy	Undeploy process (DRU)
POST	/api/1.0/processes/{id}/execution	ogcapi:execute	Execute process
GET	/api/1.0/jobs	openid	List own jobs
GET	/api/1.0/jobs/{jobId}	openid	Job status
GET	/api/1.0/jobs/{jobId}/results	openid	Job results (IPFS)
DELETE	/api/1.0/jobs/{jobId}	openid	Dismiss job

Admin

Local auth

Admin login

User	Sub (AUTHENIX)	Last seen	ogcapi:deploy	bridge network grants (image-specific, one-time)
No users yet — sign in via AUTHENIX to appear here

Settings & token

Authenticated user

Subject (sub)	—
Name	—
Email	—
Scopes	—
Expires	—

Access token

—

Click to copy. This token is sent as Authorization: Bearer … on every API call.

ID token claims

— not yet received —

Decoded JWT payload from the id_token returned alongside the access token. Signature not verified client-side.

AUTHENIX endpoints

Issuer	https://www.authenix.eu
Client ID	8fd29c71-8c84-4b7c-bd39-53d26bcaeb76
Flow	Token flow — response_type=token id_token + PKCE
Token delivery	URL fragment (#access_token=…&id_token=…)
Token info	https://www.authenix.eu/oauth/tokeninfo
UserInfo	https://www.authenix.eu/openid/userinfo
Auth endpoint	—

Request additional privileges

If you need deploy or bridge network access, submit a request below. The admin will receive an email and can grant access via the Admin panel.

Current privileges: —

ogcapi:deploy — deploy, replace and undeploy process images bridge network — allow one specific process container to make outbound HTTP requests

Reason / justification (optional)

⚠ Forget Me — Right to Erasure

Permanently deletes all personal data we hold about you: your name, email, subject identifier, privilege grants, and job history. This action cannot be undone. See the Privacy Notice for details.

You must undeploy all your processes before Forget Me can be used. Go to the Process list tab to remove them first.