Deploying

YANG Studio ships as a single container that serves both the API and the web interface from one process, and it runs as a non-root user. All it needs from you is a volume to keep your models and device profiles in.

The Compose file

If you deploy things locally with Compose, this is the whole file. Save it as compose.yaml and run docker compose up -d.

# compose.yaml
services:
  yangstudio:
    image: ghcr.io/karmatek-consulting-llc/yangstudio:latest
    container_name: yangstudio
    ports:
      # host:container — change the left side if 8420 is taken
      - "8420:8420"
    volumes:
      # Your repositories, sets and device profiles live here.
      # Without this, everything is lost when the container is replaced.
      - yangstudio-data:/data
    environment:
      # Raise this if commits on your devices run long.
      YANGSTUDIO_RPC_TIMEOUT: "120"
    restart: unless-stopped

volumes:
  yangstudio-data:

Then open localhost:8420. There is nothing else to configure — no database, no separate web server, and no init step.

If you would rather keep the data somewhere you can browse, swap the named volume for a directory on the host. The path is relative to the Compose file:

    volumes:
      - ./yangstudio-data:/data

This exact file is in the repository as compose.yaml, so you can also just clone and run it.

Plain Docker

If you are not using Compose, there are two commands worth knowing, depending on what you are doing.

To try it out — it runs in the foreground, and Ctrl-C stops it:

docker run --rm --name yangstudio \
  -p 8420:8420 \
  -v yangstudio-data:/data \
  ghcr.io/karmatek-consulting-llc/yangstudio:latest

--rm removes the container when it stops, so you are not left collecting dead containers each time you restart it. It does not touch the named volume, so your repositories and device profiles survive. --name gives it a predictable name for docker logs and docker exec.

To leave it running — detached, and back after a reboot:

docker run -d --name yangstudio \
  --restart unless-stopped \
  -p 8420:8420 \
  -v yangstudio-data:/data \
  ghcr.io/karmatek-consulting-llc/yangstudio:latest

These two cannot be combined — Docker rejects --rm alongside --restart, since one asks for the container to be thrown away and the other asks for it to be brought back. Pick whichever matches what you are doing.

The image is built for both linux/amd64 and linux/arm64, so it runs natively on Apple Silicon as well as on ordinary servers. Each build publishes an SBOM and a signed provenance attestation alongside it.

What the volume holds

Make sure /data is mounted somewhere persistent. It holds your repositories, your sets and your device profiles. A container started without it will work perfectly well, and then lose everything the moment it is replaced or upgraded.

The layout inside it is deliberately plain, so you can read, diff and version-control the contents without going through the app at all:

/data
├── repositories/<name>/*.yang   # plain YANG files
├── yangsets/<name>.json         # which modules, at which revisions
├── devices/<name>.json          # connection profiles
└── cache/                       # header index, safe to delete

Device passwords are stored in plain text in /data/devices/*.json. They have to be recoverable, because the app replays them to authenticate against your devices, so they cannot be hashed the way a user password would be. Treat that volume as a secret: keep it off shared storage and out of version control.

Configuration

Every one of these is optional, and the defaults are sensible for a local deployment.

Variable	Default	Means
`YANGSTUDIO_DATA`	`~/.yangstudio`	Where repositories, sets and profiles live. `/data` in the image.
`YANGSTUDIO_HOST`	`127.0.0.1`	Bind address. `0.0.0.0` in the image.
`YANGSTUDIO_PORT`	`8420`	Port for both API and UI.
`YANGSTUDIO_RPC_TIMEOUT`	`60`	Seconds to wait for a NETCONF reply. A commit on a busy device can use most of it.
`YANGSTUDIO_CORS`	`localhost:5173`	Allowed origins, comma-separated.
`YANGSTUDIO_STATIC`	auto	Path to the built frontend.

How much machine it needs

Parsing the models is the expensive part, and the cost scales with the set you open rather than with the size of your repository. These measurements come from the IETF RFC collection:

Operation	Cost
Index a 484-module repository	0.33 s — headers only
Parse a 144-module set (11,403 nodes)	10.9 s
Re-open the same set	0.08 s, from cache
Search across 11,403 nodes	0.02 s

Large vendor-native models are the memory-hungry case, and a few gigabytes is a reasonable allowance if you plan to open those. A handful of IETF modules needs very little.

From source

Needs uv and Node 22+.

git clone https://github.com/Karmatek-Consulting-LLC/yangstudio
cd yangstudio
./run.sh

The script creates the virtual environment, installs the dependencies, and finds free ports before starting — 8420 and 5173 are both commonly in use — then prints the URLs it settled on.