# Store a claimed backend on your own VPS

The Dehook storage client keeps the app snapshot on your VPS. Functions still execute in Dehook's sandbox, and public function URLs stay the same. This self-hosts storage, not the execution service. Dehook keeps a working cache so this is not end-to-end encryption against Dehook. Existing free quotas still apply.

1. Claim the backend with email, Google or GitHub. The sign-in method does not choose storage.
2. Open Your account and select the backend. Under Use your own VPS, download its private configuration and the Linux x86_64 client. The client is the same versioned Dehook binary, running only storage mode. The published Linux x86_64 binary requires glibc 2.39 or newer. Other platforms can build the repository and use `--storage-client` with the same arguments.
3. Copy both files to the VPS, then run:

```sh
chmod 600 dehook-storage.json
chmod +x dehook-storage-client-linux-x86_64
./dehook-storage-client-linux-x86_64 --config ./dehook-storage.json --data-dir ./dehook-storage-data
```

4. In Your account, refresh client status. Once connected, choose Use this VPS as primary storage. Dehook copies the existing snapshot, reads it back and commits the storage binding only after verification. An existing, different snapshot is never overwritten.

The client connects outbound over HTTPS to dehook.me. No inbound port, domain or reverse proxy is needed. The downloaded configuration contains a capability scoped to one app's storage transport; it cannot publish functions, query the administration API, read another backend or execute commands on the VPS. Keep the configuration private and outside Git. Generating a replacement configuration invalidates the previous key.

Only fixed `state.json` and lock/atomic temporary files are used inside the selected data directory. The directory is mode 0700 and committed files are mode 0600. State is checksum-checked, app/connection-bound and size-limited. Writes use compare-and-swap versions, atomic rename and fsync. Repeated write commands are idempotent. Never edit the state while the client is running; export data through the account page instead.

The server reads the VPS before each operation and waits for write confirmation. Offline clients, rejected writes or version conflicts return errors, with no local-only success fallback. After an ambiguous error, inspect state before retrying a mutation. The client reconnects with bounded exponential backoff and honors Retry-After. A revoked key stops the client. Polling does not spend app execution/request quotas and has separate connection/rate caps.

To revoke a lost client, use Revoke client. If it was primary storage, app requests remain unavailable until a replacement client connects; revocation never silently switches to a stale local cache. To move back safely, keep the VPS online and choose Move storage back to Dehook; the latest remote snapshot is copied before switching. Moving from Google Drive or GitHub directly to this option is not supported by this first migration path.

## Run continuously with systemd

The included `dehook-storage-client.service` uses a dedicated unprivileged user. Install the binary at `/usr/local/bin/dehook-storage-client-linux-x86_64`, create `dehook-storage`, put the configuration at `/etc/dehook-storage/client.json` owned by that user with mode 0600, and create `/var/lib/dehook-storage` owned by that user with mode 0700. Install the unit in `/etc/systemd/system`, then run `systemctl daemon-reload` and `systemctl enable --now dehook-storage-client`. No operating-system migration or reboot is needed.

Back up the data directory and keep its configuration private. Preserve both when moving the client to another host. Only one client may use a data directory; an OS file lock prevents concurrent writers.