Dynapps's deployment of SystemPrompt. This repository contains the server configuration, admin interface, MCP integrations, skills and branded desktop Bridge. The server links the systemprompt Rust library; Dynapps-specific behavior lives in the extension crates and service configuration.
This README covers local development and points to installation and release procedures. Requests sent through the gateway and connected MCP services are subject to their configured access rules and audit handling. Local client actions require the corresponding client integration.
- Use the deployed platform: start at https://dynapps.systemprompt.io and follow its sign-in and client setup instructions.
- Install a released server: follow Docker installation. Access to the private GitHub package is required; no Rust build is needed.
- Develop locally: use the steps below. Building the Bridge is a separate, optional step.
- Operate your own deployment: see single-node installation or multi-node installation.
You need repository access, Git, Docker with Compose, just, Bash, curl, jq, Python 3 and Rust installed through rustup. The workspace requires Rust 1.96+ and pins its toolchain in rust-toolchain.toml. Provide an Anthropic, OpenAI or Gemini API key for inference.
git clone https://github.com/systempromptio/systemprompt-dynapps
cd systemprompt-dynapps
just setup-local
just startsetup-local prompts for a provider, creates .systemprompt/profiles/local/, starts PostgreSQL 18, builds the release workspace, runs migrations, bootstraps an admin and publishes web assets. HTTP defaults to port 8080; PostgreSQL defaults to 5432. Open http://localhost:8080/admin/login after startup.
The bootstrap admin email defaults to git config user.email, then admin@localhost.localdomain. To choose it explicitly, or run another clone on different ports:
just setup-local <anthropic_key> "" "" 8081 5436 you@example.comThe positional arguments are Anthropic key, OpenAI key, Gemini key, HTTP port, PostgreSQL port and admin email. The first supplied provider key becomes the default provider.
On Linux, setup can fetch a matching release using an authenticated gh CLI before provisioning. The current recipe still runs a release build later, so install Rust for this path. Use the published Docker image for installation without compiling.
Additional workflows have their own dependencies. Before using the requirements workflow outside Docker, follow its runtime setup, including Node dependencies, the approval signing seed and evaluator credentials.
Build the Bridge before generating a short-lived connect code:
just bridge-buildThe Bridge is a separate Cargo workspace and depends on an unpublished Core crate at ../systemprompt-core. The recipe clones Core if absent and checks a clean existing checkout against bridge/CORE_REF. Resolve a reported mismatch before building; do not replace another developer's local changes.
Sign in or register at /admin/login, subject to the configured authentication and email-domain rules. Open /admin/profile and generate a connect code, then run:
just claude <code>
# For a gateway on another port:
just claude <code> http://localhost:8081This runs Claude Code in a container without configuring the host's Claude installation. Credentials persist in storage scoped to the clone and gateway; subsequent runs can use just claude. For a non-default gateway, use just claude "" http://localhost:8081.
just claude-reset clears this clone's client state so the next run exercises sign-in again. A successful fresh connection must report that it is signing in with the supplied code, rather than reusing a stored credential.
For host installation and desktop clients, see Bridge documentation. just connect <code> installs on the host and changes its client configuration and service setup.
| Path | Contents |
|---|---|
src/ |
Thin server entry point and extension imports. |
extensions/ |
Rust web, CLI and MCP capabilities. |
services/ |
Provider routing, access rules, MCP servers, skills, plugins and workflow configuration. |
bridge/ |
Branded client, built separately from the server. |
storage/ |
Web assets and local content. |
tests/ |
Rust test workspace. |
deploy/, docs/ |
Installation, operations and release procedures. |
services/config/config.yaml lists the flat resource files. Skills and plugins are discovered from their nested directories. Deployment profiles under .systemprompt/profiles/ hold environment-specific settings and secret references. See CLAUDE.md for development conventions and gateway routes for inference configuration.
just build-status # inspect shared build state before compiling
just server-status # inspect the running server and binary
just build # debug build; use --release for a release build
just publish # publish web assets
just verify # static checks, lint and Rust tests
just preflight # release gate, including coverage and browser checks
just stop # stop local services cleanlyEmbedded public-site templates require a rebuild and server restart before publishing. Use CLI help through systemprompt --help to discover operational commands. The demo directory contains preflight and data-seeding helpers; use those only on an instance intended for demo data.
Work on next; main is the release branch. The checked-in patch blocks are currently commented out, so the server resolves Core from crates.io. Check both Cargo.toml and tests/Cargo.toml when changing dependency mode; the branch name alone does not establish which Core is built.
For unreleased Core development, enable both patch blocks; they resolve to the sibling checkout ../systemprompt-core (the test workspace uses the corresponding relative path). Version pins in both workspaces must match that Core version, or Cargo can ignore the patch. bridge/CORE_REF separately pins the Core revision used by CI.
Follow the release procedure for version changes, migrations, offline query caches and promotion. The branching guide describes the patch-active development cycle; inspect the manifests for the current state.
| Environment | Address and behavior |
|---|---|
| Dynapps endpoint | https://dynapps.systemprompt.io — verify releases against this endpoint. |
| SystemPrompt test environment | https://dynapps.systemprompt.io — the local Fly profile is named production. |
just deploy targets the Fly test environment, not the Dynapps endpoint. With Core patches active, just deploy refuses unless ../systemprompt-core is clean at bridge/CORE_REF, so the image is built from a committed core. A registry push alone does not verify deployment to the Dynapps endpoint.