Skip to main content
Devset exposes a set of server-level settings that control the port it listens on, where it stores its SQLite database, which browser origins are permitted to make requests, and how many workflow runs it executes concurrently. You configure these settings by passing environment variables to the process or container at startup. Changes take effect after a restart.

Settings Reference

SERVER_PORT
integer
The port on which the Devset server listens for HTTP requests. Defaults to 8082. When running in Docker, map this container port to the host port of your choice with -p <host-port>:8082.
SPRING_DATASOURCE_URL
string
The JDBC URL for the SQLite database file that stores connectors, workflow definitions, and run history. Defaults to jdbc:sqlite:/data/devset.db inside the container. Change this to point at a different file path if you want to store data elsewhere or share a database across restarts without a named volume.
DEVSET_CORS_ALLOWED_ORIGINS
string
A comma-separated list of origins that the Devset API will accept cross-origin requests from. Defaults to http://localhost:5173 for local development. When running in Docker or on a server, set this to the URL your browser uses to access Devset — for example https://devset.example.com — otherwise the UI will be blocked by the browser’s cross-origin policy.
DEVSET_ENGINE_MAX_ACTIVE_RUNS
integer
The maximum number of workflow runs that Devset will execute concurrently. Defaults to 10. Increase this value on machines with more resources, or lower it to limit resource usage during busy periods.
DEVSET_ENGINE_MAX_EXECUTIONS_PER_RUN
integer
The maximum number of executions (step iterations) allowed within a single run. Defaults to 10. This cap prevents a misconfigured workflow from running indefinitely.

Docker Configuration Example

Pass environment variables directly to the container with the -e flag. The example below remaps the server to host port 9000, raises the concurrency limit, and mounts a named volume so that data persists across container restarts.
docker run -p 9000:8082 \
  -e DEVSET_ENGINE_MAX_ACTIVE_RUNS=20 \
  -e DEVSET_ENGINE_MAX_EXECUTIONS_PER_RUN=20 \
  -e DEVSET_CORS_ALLOWED_ORIGINS=http://localhost:9000 \
  -v devset-data:/data \
  ghcr.io/devset-io/devset-ce:latest
If you change SERVER_PORT you will also need to update DEVSET_CORS_ALLOWED_ORIGINS so that the UI origin continues to match the configured allow-list.

Data Persistence

Devset stores all of its state — connectors, workflow definitions, and run history — in a single SQLite file. By default the container writes this file to /data/devset.db. If you stop or remove the container without a volume mount, that data is lost. Mount a named Docker volume or a host directory to the /data path to ensure your data survives container lifecycle events:
# Named volume (recommended for Docker-managed persistence)
docker run -v devset-data:/data ghcr.io/devset-io/devset-ce:latest

# Host directory (useful when you want direct file access)
docker run -v /my/local/path:/data ghcr.io/devset-io/devset-ce:latest
To override the database location entirely, set SPRING_DATASOURCE_URL to a different path:
-e SPRING_DATASOURCE_URL=jdbc:sqlite:/custom/path/devset.db

Security Considerations

Devset does not include built-in authentication. Do not expose the Devset port directly to the public internet without placing an authenticating reverse proxy (such as nginx, Caddy, or a cloud load balancer) in front of it. Restrict access to trusted networks or use VPN tunneling when running Devset in a shared environment.
If you need to allow the Devset UI to be served from a domain other than localhost, update DEVSET_CORS_ALLOWED_ORIGINS to include that domain. Avoid using a wildcard (*) in production environments, as it permits any origin to make API requests to your Devset instance.