Can I install the OpenClaw Marketplace image on an existing Droplet?

No. Use the Marketplace image for a fresh Droplet. Keeping the assistant on its own server reduces the chance that its setup or tool access affects an existing application.

What size should I start with for a personal OpenClaw assistant?

DigitalOcean's current OpenClaw page recommends 4 GB RAM and 2 vCPUs for one to five personal users. Increase capacity only when your channels, sandbox instances, browser automation, or observed resource use justify it.

Should I enable every tool capability so the assistant is useful?

No. Start with the least access that completes one private task. Add capabilities only after you understand their data and execution boundary, and prefer a dedicated Droplet for broader tool access.

What is the smallest useful first success test?

Pair the dashboard from your own device, connect one private channel, send one harmless message from your own account, and confirm an unpaired account cannot invoke the assistant. Record the active provider, channel, and tool permissions before you add anything else.

← All guides GitHub

AI Operations

Run a Private, Always-On OpenClaw Assistant

September 1, 2026

Deploy OpenClaw on a fresh Droplet, pair one private channel, and verify its service and access boundary before you grant broader access.

Jump to steps ↓GitHub: TylorMayfield/openclaw-droplet-safety-checks

The private assistant boundary

A dedicated Droplet runs the assistant. It contacts the chosen model provider and one paired channel, while tool and data access remain limited to the list you approve.

Administrator
Creates a fresh Droplet, uses an SSH key, and limits administrator access with a firewall before connecting any channel.
Boundary: Restricted administration
Dedicated OpenClaw Droplet
Runs the assistant away from existing applications so its configuration and tool permissions have their own server boundary.
Boundary: Dedicated service boundary
Model provider
Receives only the requests the assistant sends under the provider account and spend controls you chose.
Boundary: Outbound model request
Paired private channel
A harmless message from your approved account confirms the assistant responds before you add other people or channels.
Boundary: Approved account only
Permitted tools and data
Enable only the tools and data access that the first private task needs, then review each added capability.
Boundary: Explicit allow list

Important boundary: Pairing a channel does not make every account trusted. Test that an unapproved account cannot invoke the assistant before broadening access.

Choose a narrow first job

OpenClaw can connect an assistant to messaging channels, tools, and model providers. That is useful precisely because it can act for a long time. It also means a casual first deployment can expose more access than you intended.

Start with one private job that is easy to observe, such as answering your own Telegram messages or summarizing a small set of approved documents. Do not begin by giving the assistant access to a production repository, customer data, or a shared channel. A working private path tells you more than a complicated demo.

One administrator account and one SSH key you control.
One model-provider account with a spend limit or alert you understand.
One messaging account for your own test messages.
A written decision about which tools, network access, and files the assistant may use.
A cost boundary: the Droplet and your model-provider usage are separate ongoing costs, so set an alert or limit before the first real task.

Size and create a fresh OpenClaw Droplet

DigitalOcean publishes a dedicated OpenClaw 1-Click image for a fresh Ubuntu 24.04 Droplet. Its current sizing guide starts personal use at 4 GB RAM and 2 vCPUs, then increases capacity for more people and channels. Browser automation and multiple sandbox instances can need more resources, so treat the table as a starting point rather than a promise.

Create a new Droplet from that Marketplace image instead of running an installation command on an existing application server. That separation makes it easier to keep the assistant's configuration, logs, and tool permissions away from the systems it may eventually help with.

Choose the OpenClaw 1-Click image and a region near the people or services the assistant must reach.
For a personal first deployment, start with the published 4 GB RAM and 2 vCPU recommendation unless your planned workload clearly needs more.
Attach an SSH key. Avoid password SSH for this server.
Use a Cloud Firewall with SSH restricted to your administrator address or VPN range. Do not add broad inbound rules merely to make a dashboard work.

Prove the server before connecting a channel

The Marketplace image supplies an `openclaw` system service and a Caddy service. DigitalOcean notes that the control plane uses gateway authentication, firewall-level rate limiting, non-root execution, container sandboxing, and private DM pairing. Those defaults help, but they are not a substitute for checking what actually started on your Droplet.

The companion repository performs two read-only checks. It does not install software, alter execution policy, open ports, or send any token. Review the remote output before you make a configuration change. A healthy service check only establishes the server baseline; dashboard pairing and one private message are separate acceptance checks.

Before continuing: The checks connect to the named server over SSH and reveal its service state and listening TCP ports. Confirm the target is your new OpenClaw Droplet before running them.

Replace every highlighted value before running this command.

git clone https://github.com/TylorMayfield/openclaw-droplet-safety-checks.git
cd openclaw-droplet-safety-checks
chmod 700 scripts/preflight.sh scripts/check-service.sh
OPENCLAW_SSH_TARGET=root@YOUR_DROPLET_IP ./scripts/preflight.sh
OPENCLAW_SSH_TARGET=root@YOUR_DROPLET_IP ./scripts/check-service.sh

Pair the dashboard and one private channel

Connect with SSH after the Droplet has finished provisioning. The Marketplace setup flow asks you to choose a model provider and enter that provider's API key. Treat the key and the generated gateway token as secrets: do not commit them, paste them into an issue, or put them in a screenshot.

Open the dashboard URL shown by the welcome flow, then complete its device pairing from a device you control. Add one channel after the dashboard is connected. Test it with your own account before allowing another person, group, or bot to reach the assistant. If the channel supports an allow list, populate it before treating the assistant as private.

For this first channel use Telegram direct messages. In Telegram, open the verified @BotFather account, run /newbot and save the token privately. In OpenClaw’s channel configuration, set Telegram enabled, store the token in the token field and set dmPolicy to pairing. Keep groups disabled for this exercise. Restart the Marketplace openclaw service after saving.

Send the bot a message from your account to create a pending pairing request. In the same OpenClaw service-user environment used by the welcome setup, run openclaw pairing list telegram, verify your sender identity, then run openclaw pairing approve telegram YOUR_PAIRING_CODE with that request’s code. Send “Reply with the word ready.” Expect a reply only after approval.

From a second unapproved Telegram account, send the same request. It may receive pairing instructions, but must not get a model answer or trigger a tool. Leave that request unapproved. If it gets an answer, stop the service and check the active account’s dmPolicy and allowlist before continuing.

Verify the dashboard is paired with your device and does not show a connection error.
Send one harmless prompt from your own messaging account.
Confirm that an unpaired or unapproved account cannot invoke the assistant.
Record which model provider, channel, and tool permissions are active so a later change is visible.

Expand tool access deliberately

A tool-capable assistant can make network calls, run commands, and read files depending on its configuration. That is not a setting to copy from an example without a threat model. Keep the default sandboxing and non-root boundary in place, then grant the smallest capability needed for the first job.

If you decide a skill needs broader execution or network access, put that work on a dedicated Droplet rather than a server that holds your app, source checkout, credentials, or customer data. Test with a disposable account or folder. Review the tool's inputs and outputs before connecting it to anything valuable.

Do not place provider keys or gateway tokens in a Git repository.
Do not expose a management dashboard to a broad audience without device pairing and authentication.
Do not assume an assistant sandbox makes every third-party skill safe.
Remove a channel integration if you no longer review its access path.

Back up before updating, then recheck

OpenClaw's documentation warns that raw copies of a live database can be incomplete or corrupt. Use its backup tooling before an update, reset, uninstall, or machine move, and protect the resulting archive because it can contain configuration and account state.

After an update, repeat the service check, dashboard pairing check, and one harmless channel message. A version that installs successfully is not proof that the gateway, provider authentication, and channel integration still work together.

Before continuing: This writes a backup archive that can contain configuration and account state. Protect the backup directory and verify the archive before updating.

mkdir -p ~/Backups/openclaw
openclaw backup create --output ~/Backups/openclaw --verify

Check your result

Expected result: The dashboard is paired with the administrator device, the openclaw and Caddy services report active, one harmless message receives a response, and an unpaired account cannot invoke the assistant.
Stop if: Stop if a gateway token or provider key appears in a repository, terminal capture, or issue; a dashboard is reachable without the expected pairing or authentication; SSH is open broadly; or an unapproved account can use the channel.
Next step: Record the active provider, channel, and tool permissions. Create and verify a backup before any update, then repeat the private message and service checks afterward.