Run and manage RIPTON services

Use systemd commands for a native Ubuntu installation, or Docker Compose commands for the packaged single-host pilot. Do not mix the two. These instructions operate an existing, configured deployment; they do not install or upgrade it. Run commands only on hosts you administer.

On split deployments, execute each command on the host owning that service. Do not start a local PostgreSQL service when using a managed database. Commands below assume packaged unit names and default ports; use your configured values.

Record the release and configuration in use. Securely back up the database, stable environment secrets, node state, and stored files as appropriate. Do not rerun installers, regenerate secrets, delete volumes, or change storage paths just to restart a service. For an incident, capture logs before making repeated restart attempts.

First confirm that the configured database is available. Then start Control, verify readiness, start required nodes, and bring up the UI. If a service is already running, start does not restart it. Run each group on its owning host.

# Self-managed PostgreSQL host only; skip for managed PostgreSQL.
sudo systemctl start postgresql
sudo systemctl status postgresql --no-pager

# Control host
sudo systemctl start ript-control
sudo systemctl status ript-control --no-pager
curl -fsS http://127.0.0.1:8080/readyz

# Each node host
sudo systemctl start rnode
sudo systemctl status rnode --no-pager

# UI host using the packaged nginx setup
sudo nginx -t
sudo systemctl start nginx
sudo systemctl status nginx --no-pager

The readiness request uses loopback because it runs on the Control host. It is not a workspace address. A running process is not enough: complete the network and transfer checks below before declaring service restored.

After the maintenance checks, restart only the component you need. A restart briefly stops the service. For a full shutdown, stop user-facing access and transfer services before Control, and stop a self-managed database last only if required. Coordinate dependencies and active work before doing so.

# Choose only the required action on the relevant host.
sudo systemctl restart ript-control
sudo systemctl restart rnode

# For nginx configuration changes, validate before reloading.
sudo nginx -t && sudo systemctl reload nginx

# Planned full shutdown: run on the respective hosts after draining work.
sudo systemctl stop nginx
sudo systemctl stop rnode
sudo systemctl stop ript-control
# Only for a self-managed database requiring shutdown:
sudo systemctl stop postgresql

Stopping nginx alone does not stop Desktop traffic or other direct API clients. An HTTP frontend is not a transfer-drain mechanism. Do not stop a shared database merely to restart RIPTON.

The packaged Control and node installers enable their units for boot and use Restart=on-failure. This is not the same as readiness monitoring, and an intentional systemctl stop is not treated as a crash. Verify boot enablement rather than assuming it.

# On the respective service hosts:
sudo systemctl is-enabled ript-control
sudo systemctl is-enabled rnode
sudo systemctl is-enabled nginx

# If intentionally disabled, enable the required unit for future boots:
sudo systemctl enable ript-control
sudo systemctl enable rnode
sudo systemctl enable nginx

Enable changes boot behavior; it does not start a stopped unit without --now. Check database startup separately when self-managed. After a planned reboot, rerun service status, readiness, node connectivity, and a test transfer. Network-online ordering does not prove a remote database or storage mount is ready.

Run Compose commands on the Docker host from the same extracted release directory, with the same private .env and project configuration used during installation. Do not create a fresh environment or switch release versions for a routine restart.

# Verify Docker and the existing stack.
docker info
docker compose -f docker-compose.single-host.yml ps

# Start containers that already exist but are stopped.
docker compose -f docker-compose.single-host.yml start

# If containers were removed, recreate from the existing release and .env.
docker compose -f docker-compose.single-host.yml up -d

# After draining work, restart only the service requiring it.
docker compose -f docker-compose.single-host.yml restart control
# Or, for a node issue:
docker compose -f docker-compose.single-host.yml restart rnode

# Stop the full stack for planned maintenance; preserves containers and volumes.
docker compose -f docker-compose.single-host.yml stop

# Recent logs; Ctrl+C exits log-following, not the running services.
docker compose -f docker-compose.single-host.yml logs --tail=100
docker compose -f docker-compose.single-host.yml logs -f control rnode

start requires existing containers. up -d can create or reconcile containers, so use it deliberately with the existing release configuration. restart does not apply changed container environment settings; configuration changes need a reviewed recreation procedure, not repeated restarts.

The packaged services use restart: unless-stopped. They can restart when Docker starts, but containers intentionally stopped remain stopped until explicitly started. Ensure Docker Engine is configured to start at boot on its host, then verify the stack after reboot. Compose readiness ordering is not a substitute for health checks. The Docker single-host configuration remains a protected pilot, not the production HTTPS deployment.

# Production examples: replace with your configured addresses.
curl -fsS https://control.example.com/healthz
curl -fsS https://control.example.com/readyz
# Prompts for the configured node password; change username if needed.
curl -fsS --user rnode https://node.example.com:9092/api/v1/ping
curl -fsS https://app.example.com/ >/dev/null

For the HTTP pilot only, use its configured host and ports instead of these HTTPS examples. Never disable certificate verification to make a production check pass. Keep credentials and unredacted logs out of screenshots or support messages.

1. 1Confirm that the database, Control, UI, and every required node are reachable.
2. 2Sign in to the workspace and run Check connectivity for the affected node. Check storage capacity and certificate validity.
3. 3Review interrupted or queued work and retry only after understanding the reported status; avoid creating duplicate deliveries.
4. 4Send a small non-sensitive test package, download it as the recipient, and verify the result before closing the maintenance window.

• Verify your first package end to end

  Use the upload, recipient-download, and checksum acceptance steps.

# On the relevant native hosts:
sudo journalctl -u ript-control -n 100 --no-pager
sudo journalctl -u rnode -n 100 --no-pager
sudo nginx -t

# Docker pilot:
docker compose -f docker-compose.single-host.yml ps
docker compose -f docker-compose.single-host.yml logs --tail=100 control rnode postgres ui

• Operations and troubleshooting

  Routine monitoring, logs, and incident evidence.

• Get deployment support

  Send version details and redacted diagnostics; never share secrets.

RIPTON Desktop runs on the user's workstation; it is not ript-control or rnode. Keep it open during Desktop transfers and follow the installed release's connection prompts. Closing a browser does not stop server services. Closing Desktop can interrupt its active transfer path, while browser Web Edge uploads need the browser to remain open until complete. After reopening Desktop, inspect transfer status rather than assuming completion.