BYODt Deployment

The BYODt deployment runs the whole Dethernety platform on a machine you control. It ships as a small bundle — a compose file, a control script, and a configuration template — that starts a graph database, the platform, an operator console, and a front-door proxy from published, signed container images. The platform embeds in process, with a model it downloads once.

There is no source checkout and no build toolchain. A container engine is the only prerequisite.

From the first release that ships it, each release publishes an installer, get-byodt.sh, that downloads the bundle, checks its SHA-256 and, with cosign, its signature, and asks a few questions. If Node.js 18 or later is installed, or you are happy to install it, the recommended way to run it is through npx:

npx @dether.net/byodt@0.14.0

Node.js runs the installer only; the deployment never needs it. Without Node.js, run the same installer straight from the release:

curl --proto '=https' --tlsv1.2 -fsSL https://github.com/dether-net/dethernety-oss/releases/download/v0.14.0/get-byodt.sh | sh

These commands use the current release; newer releases are listed on the releases page.

A release reaches npm in a separate step after GitHub, so for a version not on npm yet, use get-byodt.sh (see Installation → Install with the installer). You can also download and verify the bundle by hand. In the deployment's folder, one command then starts it:

./byodt up

It sets the deployment up on first run if nothing else did, and starts it every time after. ./byodt upgrade moves it to a newer release, with a backup and printed rollback steps. Everything runs locally; the deployment reaches the network only to pull its images, the embedding model's weights, and the signed module payloads for the release it is pinned to — directly, or through an outbound proxy (see Installation).

New here? Go to Installation.

What it runs

Five services, of which exactly one publishes a port.

graph LR
  B[Your browser]

  subgraph D[The deployment — one internal network]
    P[proxy<br/>the only published port]
    PL[platform]
    C[console]
    DB[(db)]
    I[console-init<br/>one-shot]
  end

  B -->|port 3000| P
  P --> PL
  P -->|/console/| C
  PL --> DB
  I --> DB
  I -.->|must finish first| PL

The database never leaves the stack network. The console is served through the front door at /console/, on the same address as the platform — one endpoint, not two.

console-init must complete before the platform starts. That ordering is declared, not hoped for: a schema problem stops the whole start, while a module or data problem is recorded and the stack still comes up, so you can read the diagnosis instead of facing a silent empty deployment.

What you reach it at

With the shipped defaults, on the machine running the deployment:

Both move together if you change the port or bind address. See Configuration.

What it needs

• A container engine — Docker with the Compose plugin, or Podman 4.1+ with a Compose provider. The control script detects which you have and remembers the choice.
• Several gigabytes of free disk and memory. The database alone needs several gigabytes: Memgraph is started with a 4096 MiB memory limit, Neo4j with a 2 GB heap plus a 1 GB page cache. The platform, which holds the embedding model in memory, runs alongside it. The model's weights take about 1.26 GB in data/models.
• A network connection for the first run and for upgrades — to pull the container images, the embedding model's weights (from Hugging Face), and the signed module payloads. An outbound HTTP proxy works; proxies that need NTLM or Kerberos login do not.

Full detail, including Podman specifics and the setup behind a proxy, is in Installation.

The control script

byodt is the deployment's control script and your whole interface to it. It wraps your container engine's compose command, carries the two configuration files every operation needs, folds first-run setup into the first start, and gives the common operations plain names:

./byodt help        # every command
./byodt setup       # the first run: choose the settings, write .env
./byodt status      # what is running
./byodt logs platform
./byodt backup
./byodt upgrade     # move to the latest release

It operates on the bundle it lives in, so it can be run from anywhere. Always go through it: the database service is in a separate file per engine, so a bare docker compose up does not start the stack. The full command reference is in Operations.

Choosing the database

The deployment runs Memgraph by default, or Neo4j 5.26 Community if you set DB_ENGINE=neo4j. Choose before the first start: each engine keeps its own data, and nothing converts one into the other. See Configuration → The database engine.

What is in the bundle

The release tarball extracts to a single directory containing these files:

./byodt setup and the first start create the rest — .env, .env.secrets, mode/, modules/, schema/, data/, tls/, and proxy-ca/, plus byodt's own records, .byodt-release and third-party-acknowledgement.log. Those are yours: they hold your configuration, your database password, and your data. Nothing in them is overwritten by a later start, and an upgrade changes .env only as it tells you, keeping a copy in its backup.

Two ways to run it

Standalone is the default and needs nothing external. The platform runs unauthenticated for a single operator on a trusted machine, with the reference data and the modules that ship with the release.

Cloud-connected is opt-in. You connect the deployment from the console to add sign-in for your team and to mount curated content packages. Nothing is sent anywhere until you do it, and it is reversible — though once connected, the controls that change the deployment, disconnect included, belong to an administrator of the deployment's team. See Cloud.

Your data never moves either way: the graph stays in your database in both modes.

Documentation map

Suggested order: Installation → Configuration → Operations. Read Cloud only if you are connecting the deployment. Keep Troubleshooting to hand.

Using the platform

These guides cover running the deployment. For using the product it serves, see the user documentation index — start with Building Your First Model.

Licensing

The Dethernety platform and the operator console are licensed under the GNU AGPL v3 (LICENSE in the bundle).

The deployment also references third-party container images — the graph database and the proxy — which your container engine pulls directly from their publishers. The bundle does not redistribute them. Read NOTICE in the bundle for their licences and provenance; note in particular that Memgraph is licensed BSL 1.1, whose production-use terms bind you as the operator directly, and that Neo4j Community Edition is licensed GPLv3.

The platform's embedding model, EmbeddingGemma 300m (Google), is not in the bundle or in any image either: the platform downloads its weights from Hugging Face on the first start. The model is licensed under the Gemma Terms of Use; the platform logs the licence before it downloads, and ./byodt models pull prints it.

Before your machine downloads any of this third-party software, the installer and byodt show a short notice that lists it, where it comes from, and its licence, and ask you to confirm that you have read it and are responsible for using that software under its licence. The confirmation is recorded in the deployment's folder. It is not a licence agreement. See Installation → The third-party notice.

For developers

The design behind this deployment — the service topology, the trust boundaries, the one-shot's exit discipline, and the console's state model — is described in the BYODt architecture set.