Windows Installation

The Windows installer sets up Curiosity Workspace on a single host, running as a Windows service. It is intended for evaluations and small single-host deployments. For production at scale — infrastructure as code, rolling upgrades, centralized secrets, several environments on parity — use Docker or Kubernetes instead.

This page installs the workspace as the curiosity service running as LocalSystem, with the binaries in E:\Curiosity, everything the workspace writes in E:\CuriosityData beside it, and the configuration in machine-scope environment variables. Because nothing lives in a user profile, the same layout also works under a dedicated domain or local account or a gMSA — see Service account for the extra steps those need. Keeping the written folders out of the install folder is also what lets that folder stay read-only for the service account.

The section is split in three pages:

This page — install, sign in, expose the workspace, upgrade, uninstall.
Service account — run the service as a dedicated user or a Group Managed Service Account (gMSA) instead of LocalSystem.
Service reference — what configure-windows-service.ps1 does, the service command line, and the start error codes.

Before you start

Match the installer to the host — x64 or ARM64 — and install from an account with local administrator rights.
Decide which account will run the service. The first start creates the workspace data, so that account's file access must be in place by then.
- LocalSystem (the default) needs nothing beyond the steps on this page.
- A dedicated identity — a domain user, a local user, or a gMSA — needs the grants on Service account. A gMSA must also exist in Active Directory and be installed on the host before the service is created. Read that page first, then come back here.

Directory layout

The install folder holds the binaries, the libraries and the bundled front-end; everything the workspace writes goes under a CuriosityData folder beside it. Adjust the drive letter, but keep everything outside C:\Users: the installer's default location and every path default land inside the current account's profile, which no other account (including service accounts) can reach.

Path	Holds	Selected by
`E:\Curiosity`	Application binaries, libraries, the bundled front-end	Install location chosen in the installer
`E:\CuriosityData\Storage`	Graph database (all workspace data)	`MSK_GRAPH_STORAGE`
`E:\CuriosityData\Logs`	Application logs	`MSK_LOG_PATH`
`E:\CuriosityData\Logs\Audit`	Audit logs	`MSK_AUDIT_LOG_PATH`
`E:\CuriosityData\Temp`	Scratch space for parsing/indexing	`MSK_GRAPH_TEMP_FOLDER`
`E:\CuriosityData\www`	The front-end the server serves, rewritten on every start	`MSK_WWW_FOLDER`

.\configure-windows-service.ps1 setup proposes exactly this: it asks for one data folder, defaults it to the install folder's name with Data appended next to it, and derives the five paths from it.

Without the first four variables, data goes to %APPDATA%\Curiosity Workspace\storage, temp files to %TEMP% and logs to a Curiosity folder inside temp — all in the profile of whichever account runs the process. Each account then silently gets its own empty workspace, and data, logs and temp churn end up on the system drive.

Keeping the install folder read-only

With those five variables set, the running service writes nothing inside E:\Curiosity, so the service account needs only read and execute there. Two things have to be in place for that:

MSK_WWW_FOLDER. The server rewrites the folder it serves the front-end from on every start. Unset, that folder is wwwroot inside the install folder, which the service account then has to be able to modify. Pointing it at E:\CuriosityData\www moves the only run-time write out; the server fills the empty folder from the bundle beside curiosity.exe on the next start.
MSK_LOG_PATH. Unset, configure-windows-service.ps1 adds --MSK_LOG_PATH="<install folder>\logs" to the service command line so the logs do not land in the service account's temp folder — again a write inside the install folder. The guided setup sets the variable instead, and then adds no override.

Language models are downloaded into the install folder

Enabling a language downloads Catalyst.Models.<Language>.dll and Catalyst.ConceptNet.<Language>.dll next to curiosity.exe — there is no variable that moves them. On a read-only install folder the download fails and the language cannot be enabled.

Fetch them as an administrator, before locking the folder down (download-all-languages fetches every language instead of English only):

E:\Curiosity\curiosity.exe download-default-languages

Enabling a further language later needs the same command again, or write access for the duration.

Read-only means read-only for the service account: the installer and an upgrade run as administrator and replace the install folder's contents. Nothing in E:\CuriosityData is touched by either.

Install

Download the installer

Get the latest installer from https://downloads.curiosity.ai/workspace/windows, in the architecture (x64 / ARM64) of the host.

Run the installer as Administrator

On the Destination Folder page, change the install location to E:\Curiosity. The default, %LOCALAPPDATA%\Curiosity Workspace, is inside your own profile.

Run the guided setup

The install folder ships configure-windows-service.ps1. Run it from an elevated PowerShell prompt, not from a Command Prompt — reaching it from cmd.exe means going through powershell.exe, which has then had its command line rewritten by cmd first, and the script says so.

cd E:\Curiosity
.\configure-windows-service.ps1 setup

If the execution policy blocks the script (… cannot be loaded because running scripts is disabled), lift it for that session only — Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass — or unblock the file once with Unblock-File .\configure-windows-service.ps1.

It asks three things:

The data folder — E:\CuriosityData in the layout above, proposed beside the install folder. The five MSK_* path variables are derived from it, so nothing the workspace writes lands in the install folder.
Whether to seed the admin account through MSK_ADMIN_USER, MSK_ADMIN_EMAIL and MSK_ADMIN_PASSWORD. Say yes: without them the credentials are admin / admin.
Which account the service runs as — LocalSystem, a user account, or a gMSA. Pick LocalSystem unless you prepared an identity on Service account.

It then prints a plan in which every item is [done] or [todo], and applies the [todo] items once you confirm: the variables at machine scope, the folders, the file access and Log on as a service right for an account other than LocalSystem, and the curiosity service itself, created and started. An existing install that keeps its current four paths is not moved — MSK_WWW_FOLDER is then left alone as well, because a workspace that has published its own front-end serves it from that folder. Warnings are printed but do not stop the script — read them. A folder the service account cannot use shows up later as error 1053.

Running setup again is safe: it reports everything as [done] and only restarts the service. Service reference lists everything it checks and applies. To do the same work by hand, see Configuring by hand below.

Sign in

Open http://localhost:8080 and sign in as admin with the MSK_ADMIN_PASSWORD you set. Without the MSK_ADMIN_* variables the credentials are admin / admin — change them immediately under Settings → Accounts → Users.

If the service did not start, Get-Service curiosity shows its state and Service start errors decodes the code the script printed.

For a quick interactive trial you can also start the workspace from its Start Menu entry instead of as a service. It then runs under your own account.

Configuring by hand

The guided setup is the same work as the steps below, done interactively. Do them by hand when you manage the configuration through Group Policy or a provisioning tool, or when you want to see each piece.

Set the configuration at machine scope. All configuration is MSK_* environment variables (see the Configuration reference). Set them at machine scope, before the first start — MSK_GRAPH_STORAGE decides where the workspace is created. Run either form from an elevated prompt:

setx /M MSK_GRAPH_STORAGE     "E:\CuriosityData\Storage"
setx /M MSK_LOG_PATH          "E:\CuriosityData\Logs"
setx /M MSK_AUDIT_LOG_PATH    "E:\CuriosityData\Logs\Audit"
setx /M MSK_GRAPH_TEMP_FOLDER "E:\CuriosityData\Temp"
setx /M MSK_WWW_FOLDER        "E:\CuriosityData\www"
setx /M MSK_ADMIN_USER        "admin"
setx /M MSK_ADMIN_EMAIL       "admin@example.com"
setx /M MSK_ADMIN_PASSWORD    "SUPERSTRONGPW123"

[Environment]::SetEnvironmentVariable("MSK_GRAPH_STORAGE",     "E:\CuriosityData\Storage",    "Machine")
[Environment]::SetEnvironmentVariable("MSK_LOG_PATH",          "E:\CuriosityData\Logs",       "Machine")
[Environment]::SetEnvironmentVariable("MSK_AUDIT_LOG_PATH",    "E:\CuriosityData\Logs\Audit", "Machine")
[Environment]::SetEnvironmentVariable("MSK_GRAPH_TEMP_FOLDER", "E:\CuriosityData\Temp",       "Machine")
[Environment]::SetEnvironmentVariable("MSK_WWW_FOLDER",        "E:\CuriosityData\www",        "Machine")
[Environment]::SetEnvironmentVariable("MSK_ADMIN_USER",        "admin",                        "Machine")
[Environment]::SetEnvironmentVariable("MSK_ADMIN_EMAIL",       "admin@example.com",            "Machine")
[Environment]::SetEnvironmentVariable("MSK_ADMIN_PASSWORD",    "SUPERSTRONGPW123",             "Machine")

Neither form changes the console you are typing in — open a new prompt before checking the values with echo %MSK_GRAPH_STORAGE% or $env:MSK_GRAPH_STORAGE.

The three MSK_ADMIN_* variables go together: a password without user and email stops the workspace from starting (Failed to create the admin account in the log). They are applied on every start, not only the first — rotate the password by changing the variable, or clear MSK_ADMIN_PASSWORD once the account exists to manage it from the UI. See How the admin account is seeded.

A service only sees machine-scope variables

A variable set with setx without /M, in the User variables half of the System Properties dialog, or only in the console you are typing in exists for your account alone: the service starts without it and silently falls back to the per-account defaults above. configure-windows-service.ps1 warns about every MSK_* variable that exists for your user or session but not at machine scope.

Restart the service after changing a variable. If it still starts with the old value, restart the host: the Service Control Manager may keep the environment it read at boot.

Grant the service account access — only for an account other than LocalSystem. Follow Service account before the next step.

Create and start the service. Run the script with configure from an elevated PowerShell prompt - the mode that asks nothing. It checks the MSK_* variables and the folders the service will use, creates any data, log or temp folder that is missing, then creates the curiosity service running as LocalSystem and starts it. An existing service is updated in place and keeps its account.

cd E:\Curiosity
.\configure-windows-service.ps1 configure

Set MSK_LOG_PATH before this step if the install folder is to stay read-only: without it the script writes --MSK_LOG_PATH="E:\Curiosity\logs" into the service command line.

To run the service under a prepared identity instead, switch the account and restart. To create the service without the script, see The service command line.

Firewall and TLS

By default the workspace listens on 8080. If you expose it beyond localhost:

Open inbound TCP 8080 (or your MSK_PORT) in Windows Defender Firewall.
Terminate TLS at a reverse proxy (IIS with ARR, Nginx for Windows), or set MSK_CERT_FILE and MSK_CERT_FILE_PRIVATE_KEY on a PEM certificate readable by the service account, or set MSK_CERT_FROM_STORE_NAME to the certificate's DNS name to load it from the Windows certificate store.
Set MSK_PUBLIC_ADDRESS to the URL clients will use.

`MSK_CERT_FROM_STORE_NAME` reads the service account's store

The certificate is looked up by subject name or SAN in Cert:\CurrentUser\My of the account running the service — not LocalMachine, and not the store you see in your own MMC session. The certificate must have its private key. To import a certificate into a gMSA's personal store, run certutil -user -importPFX <file> through a scheduled task running as the gMSA — see Running a command as the gMSA. MSK_CERT_FROM_STORE_NAME takes precedence over MSK_CERT_FILE when both are set.

Upgrading

Take a backup of E:\CuriosityData\Storage (see Backup and restore).
Stop the service: sc.exe stop curiosity.
Run the new installer and select the same install directory (E:\Curiosity).
Start the service: sc.exe start curiosity.

Data and configuration are untouched — they live outside the install directory. For breaking changes, walk Upgrades and migrations first.

Uninstalling

Stop and remove the service (sc.exe stop curiosity, then sc.exe delete curiosity), then use Settings → Apps & features → Curiosity Workspace → Uninstall. The uninstaller removes the installed binaries and leaves data in place. To delete the workspace, manually remove E:\CuriosityData.