Skip to main content

Share the local console on a team server

By default the Vulkro for Salesforce console runs on your own machine: vulkro-sf serve starts a local web app, binds to loopback (127.0.0.1), and opens your browser. Nothing leaves the machine.

You can also run one console on a shared server and let a small team open it from their browsers. It is the same published vulkro-sf binary and the same point-in-time, offline engine: it never sends your source, metadata or findings anywhere. Set VULKRO_OFFLINE=1 on the server to stop it making any outbound call at all.

Looking for a hosted team workspace?

This page is about sharing the local console. For per-user roles, single sign-on, scheduled scans of every org and an activity log, see Vulkro Cloud, or Vulkro Cloud on your own servers to run the full product on your own infrastructure.

The model​

  • Point-in-time, offline scanner. A scan reflects the code and (if you run the org passes) the org configuration at the moment it ran. There is no always-on agent and no background polling.
  • One shared console, one access token. The server holds the projects, scans and triage decisions in a SQLite database in its data directory. Everyone who has the access token sees the same state. There are no per-user accounts.
  • Org access stays with the sf CLI. Live-org passes shell out to the sf CLI on the machine where they run. The console holds no Salesforce token of its own. See Live-org setup for the precise privacy contract.
  • No vendor round-trip. The console does not send scans to Vulkro. Running it on a server only moves where the binary runs.

Install the binary on the server​

Use the same one-line installer as on a laptop (see Install):

curl -fsSL https://dist.vulkro.com/install-sf.sh | bash
vulkro-sf --version

Configure it​

The console always requires an access token. On a laptop a new random token is minted on every start and printed in the console link. On a shared server, set your own, because a network bind is refused without it:

VariableDefaultPurpose
VULKRO_SERVE_TOKENA new random token per startThe access token. Required for any non-loopback bind. It is not printed: sign in with it at the console's sign-in page, or open <console address>/?token=<token>. The general vulkro serve console honours the same variable.
VULKRO_SF_BIND127.0.0.1Bind address. Loopback keeps the console local-only. Set 0.0.0.0 to expose it on the network (then put a reverse proxy in front, below).
VULKRO_SF_PORTA free port the system picksPin a fixed port. The --port flag overrides it.
VULKRO_SF_DATA_DIR~/.vulkro-sf/dataDirectory for the SQLite database and on-disk state. Put it on a disk that is backed up.
VULKRO_SERVE_ALLOWED_HOSTS(none)Comma-separated hosts (for example sf.internal:8443) whose Origin the console also accepts, for a console behind a reverse proxy that rewrites Host.

A browser that presents the token gets an HttpOnly, SameSite=Strict session cookie. Scripts send it as Authorization: Bearer <token>. A request without the token gets HTTP 401, and a request sent by another web page gets 403. Rotating VULKRO_SERVE_TOKEN signs every browser out.

Run it​

export VULKRO_SERVE_TOKEN="$(openssl rand -hex 24)"   # keep it in your secret store
export VULKRO_SF_BIND=127.0.0.1                        # the reverse proxy reaches it on loopback
export VULKRO_SF_PORT=8923
export VULKRO_SF_DATA_DIR=/var/lib/vulkro-sf
vulkro-sf serve --no-browser

To keep it running, start the same command from your service manager (for example a systemd unit) with those variables set, as a non-root user that owns the data directory.

Put a reverse proxy in front​

Terminate TLS in a reverse proxy, not in the console:

  1. Keep the console on loopback (or an internal-only network).
  2. Run a reverse proxy (for example Caddy or nginx) that listens on 443, terminates TLS, can add your own SSO in front, and proxies to the console.
  3. Publish only the proxy. If the proxy rewrites Host, list the public host in VULKRO_SERVE_ALLOWED_HOSTS.

What this is not​

  • Not multi-user. Everyone with the token shares one project list and one triage queue. There is no per-user or per-team separation.
  • Not a managed service. You run and patch the server. Upgrade the binary with vulkro-sf update (see vulkro-sf update) and restart the service.

For the single-developer workflow you need none of this: run vulkro-sf serve and use the console locally. See Install and Your first scan.

Last updated on