DK Studio/Documentation
ProductChangelog

Deployment modes

DK Studio ships in two modes: a hosted studio operated by DK Studio, and an in-house installation running on infrastructure you control. They are the same product — the same REST API, the same agent protocol, the same case model, the same reports. This page compares them, explains how to choose, and covers moving from one to the other.

The two modes at a glance

QuestionHosted studioIn-house installation
Who operates the studioDK StudioYou
What you installThe agents on your benchesThe studio, the socket server, the database
Where the data livesWith DK StudioOn your infrastructure
How agent licences are issuedFrom the admin screen of the hosted studioFrom the admin screen of your studio
What happens when a bench is offlineThe bench's commands wait; other benches are unaffectedThe same — the connection model is unchanged
How you reach the studioA browser, over httpsA browser, over http or https on your network

Hosted studio

In the hosted mode the studio runs on DK Studio's infrastructure. The team works in a browser; there is nothing to install except the agents on the benches.

The agents are the same agents you would install yourself. They reach the hosted studio over the outbound connection they already make — an http or https URL, and the studio's own port. The bench needs no inbound port, no port forwarding and no VPN client.

Licensing is per agent. An administrator opens Admin → Licences, issues a licence, and hands the licence code to the bench operator. The licence is one seat for one bench, and the same revocation rules apply as in an in-house install. See Agent registration and entitlements.

The connection model does not change

Hosted does not mean the studio calls your benches. The agent dials out to the hosted studio over the same two channels it uses for an in-house install — the Socket.IO push path and the REST polling fallback — and the hosted studio never dials back. See Network requirements.

In-house installation

The studio, the socket server and the database all run on infrastructure you control. One studio process serves the UI, the REST API and the Socket.IO endpoint on port 3000.

The database engine is chosen at setup:

EngineDriverNotes
SQLitebetter-sqlite3The default. The database is a file under DATA_DIR.
PostgreSQLpgServer-based.
MySQLmysql2Server-based.

The schema is applied at setup by the wizard's initialize step (POST /api/system/setup with {"step":"initialize"}), from the three parallel DDL files, each defining the same 21 tables.

Configuration comes from two places:

  • Environment variables — PORT, HOSTNAME, NODE_ENV and DATA_DIR for the studio, and AGENT_PORT and AGENT_HOST for the agent.
  • Files in the working directory — .db-config.json (the engine and its connection details), .studio-license.json, .setup-progress.json and the .setup-complete marker.

The full procedure, the start order, the backup and restore steps are in Self-hosted deployment.

What is identical in both modes

  • The agent always dials out. No inbound port is opened on a bench or on the studio's server, in either mode.
  • The same REST API. The same endpoints, the same request and response bodies.
  • The same agent protocol. The same socket envelope, the same handshake, the same command vocabulary.
  • The same case model, the same runs, the same reports. A case written for one mode runs in the other without change.

The mode is a decision about where the processes run, not about what the product does.

Choosing a mode

Choose the hosted studio when the team wants to work on the platform without operating a server, and the data the runs produce is not restricted by an internal policy. Choose an in-house installation when the case definitions, the run results and the evidence they contain have to stay inside your network, or when the studio has to sit on a network the bench can reach but nothing else can.

Moving between modes

The schema is the same in both modes, so a migration is a database movement plus a change of address.

In-house to hosted. Take a dump of the database, load it into the hosted studio, and point the agents at the hosted studio's URL. The agent rows and their credentials move with the dump, so a bench keeps its identity; what changes is the studioUrl it is registered against.

Hosted to in-house. Take a dump from the hosted studio, restore it into an engine you control, write the matching .db-config.json in the studio's working directory, and start the studio. The agents are pointed at your studio's URL and re-registered there.

Two things to check after either move:

  • The licence seats. Agent licences are rows in the database and travel with it. Confirm that the number of seats matches the fleet you are about to run.
  • The command history. The database carries the command records and their results. A dump carries them into the new home, and they carry whatever those commands printed.

The security consequence of each mode

Hosted studioIn-house installation
Where the case definitions and run results liveWith DK StudioOn your infrastructure
Who can read the databaseDK Studio's operators, and you, by roleWhoever holds the database credentials
Where the backups areTaken by DK StudioTaken by you, under your retention policy
What a script printed to stdoutRecorded in the command history, with DK StudioRecorded in the command history, with you
What leaves your networkThe agent's outbound connection, and the data in itNothing

In the hosted mode, the data of a digital key programme — the case definitions, the run results, the captured screens and anything a bench command printed — lives with DK Studio. In the in-house mode it never leaves your network, and the database is the last line of defence: whoever holds the database credentials holds everything the studio holds.

The rest of the security model is the same in both modes. The session cookie expires after seven days, agent credentials are sent in request bodies and socket payloads rather than in headers, and licence codes are shown once, at issue. See Security and privacy.