Deploy RIPTON for production

This procedure covers native systemd services on Ubuntu 22.04/24.04 x86_64 with PostgreSQL 14 or newer. It is not a Kubernetes or cloud-provisioning recipe. Use the INSTALL.md supplied with your exact release as the operational reference. Your infrastructure owner must prepare DNS, trusted certificates, the database, reverse proxy, storage mounts, and backups.

Obtain the Linux amd64 release archive and its published SHA-256 from your RIPTON delivery contact. Replace VERSION with your supplied version. Work from the extracted release root on the target server, not a source checkout. Review RELEASE_MANIFEST.md and the bundled INSTALL.md for your exact version.

sha256sum ripton-release-VERSION-linux-amd64.tar.gz
# Compare with the separately supplied checksum before extracting.
tar -xzf ripton-release-VERSION-linux-amd64.tar.gz
cd ripton-release-VERSION
test -x bin/linux-amd64/ript-control
test -x bin/linux-amd64/rnode
test -x bin/linux-amd64/ripton
test -f ui/dist/index.html

Create a dedicated login role and a database owned by that role through your database administrator's or managed provider's workflow. Store the connection URL privately, configure database TLS, and restrict access to Control hosts. Confirm backups and rehearse a restore before storing customer data. Control applies migrations on startup; back up an existing database before upgrading.

sudo scripts/install-control-systemd.sh
sudo install -m 0755 bin/linux-amd64/ripton /usr/local/bin/ripton
sudoedit /etc/ript-control/env

Replace every template value before starting. Generate the two stable secrets once with openssl rand -hex 32 and openssl rand -base64 32, then store them in your secret-management and encrypted-backup system. Do not regenerate the database node-secret key after nodes are registered.

# /etc/ript-control/env — replace placeholders
CONTROL_HTTP_ADDR=:8080
CONTROL_ENV=production
CONTROL_PLANE_ID=customer-site-1-control
CONTROL_DATABASE_URL=postgres://ript:PASSWORD@db.example.com:5432/ript_control?sslmode=require
CONTROL_EXTERNAL_TOKEN_SECRET=REPLACE_WITH_RANDOM_HEX_32_BYTES
RIPT_DB_NODE_SECRET_KEY_B64=REPLACE_WITH_RANDOM_BASE64_32_BYTES
CONTROL_CORS_ALLOWED_ORIGINS=https://app.example.com
CONTROL_REQUIRE_HTTPS_NODE_BASE_URL=true
CONTROL_LOG_FORMAT=json

List exact browser origins in CORS, comma-separated without paths or trailing slashes. Keep the public application origin first. Multiple Control instances use the same database and stable secrets, with a unique CONTROL_PLANE_ID for each instance; follow the topology guidance for your release.

sudo systemctl restart ript-control
sudo systemctl status ript-control --no-pager
# Run on the Control host.
curl -fsS http://127.0.0.1:8080/healthz
curl -fsS http://127.0.0.1:8080/readyz

Expose Control through your trusted HTTPS proxy or load balancer. Keep the internal unencrypted listener restricted, rather than exposing it directly to end users.

sudo RNODE_STORAGE_ROOT='/data/ripton/rnode' scripts/install-rnode-systemd.sh
sudoedit /etc/rnode/env

Choose a mounted volume with enough capacity before installation. The storage path must match the path passed to the installer because the systemd filesystem allowlist is generated from it. Replace the hostname and password below.

RNODE_LISTEN_ADDR=:9092
RNODE_AUTH_USER=rnode
RNODE_AUTH_PASS=REPLACE_WITH_UNIQUE_RANDOM_PASSWORD
RNODE_STORAGE_ROOT=/data/ripton/rnode
RNODE_DATA_DIR=/var/lib/rnode
RNODE_JOB_STORE=sqlite
RNODE_ADVERTISE_HOST=node.example.com
RNODE_UDP_PORT_BASE=33001
RNODE_UDP_PORT_COUNT=8

Obtain a trusted full certificate chain and matching private key for the node hostname from your certificate-management system. The helper validates the material and enables node TLS. Never put private keys in the release directory or support requests.

sudo scripts/install-rnode-tls-cert.sh \
  --cert /path/from-certificate-provider/fullchain.pem \
  --key /path/from-certificate-provider/privkey.pem \
  --host node.example.com --restart
sudo systemctl status rnode --no-pager
# Prompts for the configured node password.
curl -fsS --user rnode https://node.example.com:9092/api/v1/ping

Control must trust the issuer and reach the registered HTTPS URL. Desktop must reach the advertised host and UDP range. Restrict API access to required networks. Repeat the helper with renewed certificates and recheck connectivity. If TLS terminates at a trusted proxy instead, protect the internal HTTP listener and register the proxy's HTTPS address.

The UI helper creates a basic HTTP nginx site, not a public HTTPS endpoint. Review its changes on an existing host. Your infrastructure owner must configure HTTPS, certificate renewal, host forwarding, and public HTTP-to-HTTPS redirection. The public UI origin must match Control CORS.

sudo RIPTON_CONTROL_URL='https://control.example.com' \
  RIPTON_UI_SERVER_NAME='app.example.com' \
  scripts/install-ui-nginx.sh --dry-run
# After reviewing the preview:
sudo RIPTON_CONTROL_URL='https://control.example.com' \
  RIPTON_UI_SERVER_NAME='app.example.com' \
  scripts/install-ui-nginx.sh
# After configuring the HTTPS frontend:
curl -fsS https://app.example.com/ >/dev/null
curl -fsS https://control.example.com/healthz
curl -fsS https://control.example.com/readyz

1. 1Open your deployed UI. On a clean database with no users, the first registration creates the administrator. Coordinate bootstrap on a restricted network before permitting other users to register.
2. 2Open Admin → License & Activation and install the supplied signed licence or use your activation code. Verify that the licence covers your topology. Customer-specific licences are delivered separately. If your offline licence binds exact node IDs, follow the ordering in your release's AIR_GAP_LICENSING.md instead.
3. 3Open Admin → Nodes and add the node's reachable Base URL, /api/v1 prefix, and configured node credentials. Use HTTPS in production. Run Check connectivity and assign the appropriate node as Default storage.
4. 4Install Desktop on a test workstation that can reach Control and the node transfer ports. On macOS, open desktop/macos/RIPTON Desktop.dmg, move the application to Applications, and open it. On Debian/Ubuntu use the commands below. Approve protocol-handler registration if prompted.

# Debian/Ubuntu workstation only
sudo dpkg -i 'desktop/linux/RIPTON Desktop.deb'
ripton-desktop --health
ripton-desktop --register-protocol-handler

Service health alone is not acceptance. Send a small non-sensitive file, confirm upload completion, download as the intended recipient, and compare its checksum with the original. Use the first-package walkthrough below.

• Send and verify your first package

  Follow the sender, monitoring, recipient download, and checksum steps.

• Register and troubleshoot a node

  Resolve credentials, TLS, node connectivity, and advertised-route problems.

• Operations and troubleshooting

  Inspect health and logs before retrying a failed transfer.

• Confirm a tested database restore and encrypted backups of Control and node environment files, node state, and stored files.
• Assign monitoring for database availability, service failures, node reachability, storage capacity, and failed transfers.
• Record certificate-renewal ownership, firewall rules, log retention, and the support escalation path.
• Retain the previous release and appropriate data backups. Rehearse version-specific upgrade and recovery; do not assume older binaries work against a migrated database.
• Accept the deployment only after sender/recipient verification on the intended network and completion of operational and security controls.

• Get deployment support

  Provide release versions and redacted diagnostics, never passwords, tokens, private keys, or unredacted environment files.

• Return to deployment choices

  Review the boundaries between pilot and production.

• Run and manage RIPTON services

  Start, stop, restart, check boot behavior, and verify recovery for your installation type.