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.

← All guidesAI Operations

Securely Run OpenClaw as a Private, Always-On AI Assistant

September 1, 2026

Deploy the OpenClaw Marketplace Droplet, keep its gateway private, pair one channel deliberately, and verify the service before expanding access.

Companion GitHub repositoryCompanion OpenClaw Droplet safety checksTylorMayfield/openclaw-droplet-safety-checksView on GitHub

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.

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.

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.

Edit firstReplace 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

Replace before use: YOUR_DROPLET_IP

Check the first response

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.

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.

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