> ## Documentation Index
> Fetch the complete documentation index at: https://docs.panofx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Containers and hosted platforms

> Run the node from an image on Docker, Railway, Fly or ECS.

The image is `ghcr.io/panoflow/panofx-node:<version>`, an 18 MB non-root image (user 10001) for linux/amd64
and linux/arm64. It runs in one of two modes.

## App mode

`PANOFX_MODE=app` runs the point-and-click node. Its settings and wallet live on a volume at `/data`, and you
set it up from a paired browser. This is the simplest way to run a node on a platform. The steps are under
[Run on a server](/resolvers/headless).

| Variable                    | Meaning                                                                                         |
| --------------------------- | ----------------------------------------------------------------------------------------------- |
| `PANOFX_MODE=app`           | Run the app instead of `start`                                                                  |
| `PANOFX_DATA_DIR`           | Data directory (default `/data`), which must be a mounted volume the container's user can write |
| `PANOFX_REMOTE`             | `on` (default in app mode), `auto` or `off`                                                     |
| `PANOFX_REMOTE_PAIR_SECRET` | Pair with a secret from your secret store instead of a link in the log                          |
| `PANOFX_REQUIRE_VOLUME`     | Default `1`: refuse to create a wallet unless the data directory is a volume                    |

## Policy mode

Without `PANOFX_MODE`, the container runs `start --policy /tmp/panofx/policy.yaml`. Either mount your policy
and keyfile and pass your own `--policy` path, or, on platforms that inject configuration as environment
variables, set the contents directly. The entrypoint writes them to `$PANOFX_RUNTIME_DIR` (default
`/tmp/panofx`) before the node starts.

| Variable                                                | Meaning                                                                                                                                                        |
| ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `PANOFX_POLICY_YAML`                                    | The policy file's contents. `${VAR}` references are expanded at start                                                                                          |
| `PANOFX_KEYFILE_JSON`                                   | The encrypted keyfile's contents, one line starting with `{"address"`                                                                                          |
| `PANOFX_KEY_PASSPHRASE` or `PANOFX_KEY_PASSPHRASE_FILE` | The keyfile passphrase. Only the passphrase: a value that starts with `{` is refused                                                                           |
| `PANOFX_SOLANA_KEYFILE_JSON`                            | The encrypted Solana keyfile, for a policy whose `solana_signer.keyfile` is `$PANOFX_RUNTIME_DIR/solana-keyfile.json`. Needs the 0.10.0 image                  |
| `PANOFX_EXECUTOR`                                       | Replaces the policy's `contracts.executor`, so a node follows an executor redeploy without a rewrite. With several EVM chains use `PANOFX_EXECUTOR_<chain id>` |
| `PANOFX_REGISTER_ON_START=true`                         | Re-send the signed registration before every start (idempotent), so a hosted node needs no separate `register` step                                            |
| `RPC_URL`                                               | Whatever your policy references as `${RPC_URL}`                                                                                                                |

<Note>
  A policy that uses Turnkey or MPCVault needs its API secret instead of a passphrase: see [MPC signers](/resolvers/runbook/mpc-signers).
</Note>

## Nonces and restarts

Without a persistent `data_dir` the nonce counter starts at a random Permit2 word each boot, so a restarted
container never reuses a nonce. With one, sequential nonces pack into one storage word, which is cheaper on
chain. Either is safe.

## One node per key

The relay hands the connection to the newest instance of an address, and the older one waits a minute before
retrying. If your platform starts a new container before stopping the old one, expect the log line
"replaced this connection with a newer one" once per deploy. Run a second node with a second key.