SoxDesk deployment guide (for IT)

This guide is for IT administrators deploying SoxDesk for an audit team. There are two supported patterns. Both are on-premise: SoxDesk has no cloud component, makes no outbound connections (except mail through your own SMTP server, if configured), and stores all data in a folder you choose.

Pattern A: per-user install + shared store (15 minutes)

1. Unzip SoxDesk-portable-win64.zip on each user's machine (any folder they can write to).
2. Create one shared folder on a network share, e.g. \\fileserver\audit\SoxDeskStore, writable by all SoxDesk users.
3. First user: double-click SoxDesk.cmd, complete the admin setup screen, then on the Admin page → Data store, set the store path to the shared folder and restart the app.
4. Every other install: same step — point the data store at the same folder. The whole team now works in one shared audit file.

Notes:

• The app binds to 127.0.0.1:5179 — it is not reachable from the network in this pattern.
• Concurrency is handled server-side (SQLite with DELETE journal + busy timeout, chosen specifically for reliability on SMB shares; workpaper checkout locks are atomic).
• Backups are automatic (every 6 hours, 14 kept, in <store>\backups). Include the store folder in your normal file-share backup cycle and you are fully covered.

Pattern B: central server (under 1 hour)

One SoxDesk instance on a small Windows VM; users and control owners access it by browser.

VM sizing: minimal — 2 vCPU / 4 GB RAM / a few GB of disk beyond your evidence volume is comfortable for typical internal-audit team sizes.

1. Unzip the portable package to e.g. C:\SoxDesk on the VM.
2. Decide the data-store location: a local folder on the VM (simplest, fastest) or a network share (if you want the store on managed storage). Set it on the Admin page after first run.
3. Expose the app to the network. The server binds to localhost by default; set the AF_HOST environment variable to override — but the recommended setup is to keep the app on 127.0.0.1 and put a TLS reverse proxy in front:
   • IIS: install URL Rewrite + ARR, create a site bound to 443 with your internal certificate, reverse-proxy to http://127.0.0.1:5179/.
   • Caddy (single exe, easiest): caddy reverse-proxy --from soxdesk.yourco.internal --to 127.0.0.1:5179 with an internal CA certificate.
   • Traffic between proxy and app stays on the VM; users get HTTPS end to end.
4. Auto-start: run SoxDesk as a scheduled task at startup (Task Scheduler → run SoxDesk.cmd at boot, whether user is logged on or not) or wrap it as a Windows service with a service wrapper of your choice. (A packaged service-mode installer is on the roadmap.)
5. Create a DNS name (e.g. soxdesk.yourco.internal) pointing at the VM.

Sign-in options for server mode (Admin page → Login method):

• LDAP / Active Directory — recommended for server mode. Users sign in with their normal domain credentials. Supports a service-account search-then-bind or direct UPN bind. Directory sign-in only works for users an admin has already created in SoxDesk — there is no auto-provisioning, so audit access stays controlled.
• Local passwords — fully offline, no directory dependency.
• Email one-time codes — through your own SMTP server.

PBC / control-owner usage: create control owners as member accounts. They sign in with their browser (no software installed), see their assigned items, and upload evidence. Reviewer/preparer segregation and all workflow rules are enforced server-side.

Security summary (both patterns)

• All data (SQLite database, evidence files, backups) lives in the folder you chose. No telemetry, no update checks, no license phone-home — license keys are verified offline.
• Sessions: httpOnly cookies, hashed tokens, 7-day expiry, server-side enforcement on every API route.
• Full details in the Security Overview, written for security-review teams.

Updating

Unzip the new version over the install folder (or beside it) and restart. The data store is never inside the app folder, so updates cannot touch data. Check the release notes; your license covers all builds released during your updates window.

Restore from backup

Stop the app, copy the desired soxdesk-<timestamp>.db from <store>\backups over <store>\soxdesk.db, restart. Evidence files are stored separately in <store>\attachments and are not part of the automatic DB backup — cover them with your file-share backup.

Questions during deployment: support@soxdesk.com (async, 48h). A guided-deployment option is available at purchase: we review your planned setup (patterns, store location, proxy, sign-in mode) and stay on priority response through go-live.