Tools: So You Installed OpenClaw on a Digital Ocean Droplet. Now what?

You got OpenClaw installed on a DigitalOcean Droplet using the One-Click OpenClaw Droplet. That’s awesome. But now what? How do you install skills? How do you set up environment variables? Why can’t you edit certain files? What are execution policies and why are they blocking everything? This is the guide I wish I had after installation. It covers the practical stuff that comes next – the things you need to figure out before anything actually works. If you’re a past version of me staring at a terminal wondering why your freshly installed skill is doing nothing, this is for you. Before you do anything else, it helps to understand how users work on this server. OpenClaw doesn’t run as root. It runs under a dedicated system user called openclaw. That user was created during installation specifically so the AI runtime doesn’t have root-level access to your system. The split works like this: You’ll be switching between these two users throughout this guide. When something needs to be done as a specific user, it’ll be called out. Skills teach OpenClaw how to use tools. Some are self-contained like humanizer (just a skill file), others like gog (Google Workspace) also need a binary installed separately. SSH into your droplet and switch to the openclaw user: Install a skill from ClawHub: That’s it. Humanizer is a skill-only install - no binary needed. For skills that need a binary (like gog for Google Workspace), you also install it via Homebrew: Many skills need API keys or credentials to work (e.g., TWITTER_AUTH_TOKEN for Bird, GOG_ACCOUNT for Google Workspace). These are stored as environment variables in: You can’t edit this file as the openclaw user. You’ll get a permission denied error. That’s by design. The openclaw user isn’t allowed to change its own configuration. If the runtime could rewrite its own environment variables, a misbehaving skill could change API keys, redirect outputs, or mess with settings you didn’t intend. So that file is owned by root, and only root can touch it. To edit it, first get back to root: Add whatever your skill needs: The idea is straightforward: the runtime user can’t rewrite its own environment variables or credentials. A misbehaving skill can’t swap out API keys or redirect outputs. Root stays in control of that file. After you change this file, you need to restart the service. The changes won’t take effect until you do. This is the section that would have saved me a lot of time early on. If you installed a skill and it just sits there doing nothing – no errors, no output, nothing – it’s probably an execution policy issue. These control how OpenClaw is allowed to run things on the system. Here’s what each one does. This tells OpenClaw to route all execution through its gateway process. On a VPS, there’s no terminal window open. There’s no shell session sitting there waiting. When OpenClaw needs to run a command, it needs somewhere to run it. The gateway is that somewhere – a persistent process that receives commands, executes them, logs what happened, and returns results. It works even when no one is SSH’d in. Without this, OpenClaw tries to execute things in a context that doesn’t exist on a headless server. Commands will either fail or hang. On a VPS, you need this. By default, OpenClaw may pause and ask for approval before running certain tools – a “are you sure?” type prompt. On a local machine, that’s fine. You see the prompt, you approve it, everything continues. On a VPS, there’s no one sitting there to approve anything. The command just hangs, waiting for input that’s never coming. Turning this off means commands run automatically without waiting for approval. That’s required if you want things like Telegram triggers or cron jobs to work. The tradeoff is that you’re removing a safety layer. You’re trusting that the skills you installed will behave correctly. This gives OpenClaw the highest execution tier available within its own sandbox. It does not give it root access. The openclaw user still can’t touch system files, can’t change its own config, and can’t escalate privileges. Everything from the “Set Enviornment Variables Must be Done as Root” section still holds. What it does is loosen restrictions inside the sandbox. By default, OpenClaw runs in a fairly locked-down mode where it can’t do things like make network calls, write to temp directories, or run shell commands. That’s safe, but it means a lot of skills just won’t work. The frustrating part is that when a skill gets blocked by a lower security tier, it often fails silently. No error message. No warning. The skill just does nothing. If you’ve installed something and it seems to be ignored, this is likely why. When you combine tools.exec.ask off with tools.exec.security full, you’re enabling automated execution with minimal internal restrictions. That’s the right setup when: If you’re sharing this server with other things or other people, think carefully before doing this. These settings assume a dedicated, single-purpose setup. To verify what the execution policies are currently set to, run these as root: Or to see all execution-related settings at once: You’re looking for: host set to gateway, ask set to off, and security set to full. If any of those are different, that’s likely why a skill isn’t running. Anytime you change environment variables or execution policies, you need to restart the service. None of your changes take effect until you do. This must be done as root: This reloads everything – the env file, execution policies, installed skills, and runtime configuration. If something isn’t working and you’ve checked everything else, make sure you actually restarted the service. It’s easy to forget. If you’ve followed the steps above, you’ve already seen this in practice: some things require root, some things require openclaw, and those boundaries are enforced. Here’s the full picture in one place. root owns the system. It controls configuration, manages the service, and sets execution policies. It’s the only user that can edit /opt/openclaw.env or run the config CLI. openclaw is the runtime user. It runs skills, installs packages via Homebrew, and does the actual work. But it can’t change how it’s configured. It can’t rewrite its env file. It can’t change execution policies. That’s the whole point. It can change config settings via openclaw config set, but it can’t edit the environment file (/opt/openclaw.env) - that’s owned by root. /opt/openclaw.env is the configuration file. Owned by root, read by the service at startup. The openclaw user can read the values at runtime but can’t modify the file. Execution policies control what the openclaw user is actually allowed to do inside its sandbox. Set by root, enforced by the gateway. This model exists so that: OpenClaw’s runtime environment lives inside a Docker container. If you ever want to look at what’s actually in the sandbox – the configuration files, identity files, tools, and other runtime assets – you can connect to it directly. This needs to be done as the openclaw user. If you’re currently root, switch first: Then find the container ID: You’ll see something like this: Once inside, the sandbox root is /workspace: These are the files that define how OpenClaw behaves – its identity, available tools, agent configurations, and so on. This is useful for debugging or just understanding what the runtime actually sees when it’s running. You’re viewing these as read-only exploration. The sandbox is the runtime’s world – changes to these files should be made through the proper configuration paths, not by editing them directly inside the container. Check these in order: That’s expected. You’re probably logged in as openclaw. Run exit to get back to root, then edit the file. You need to restart the service. Run systemctl restart openclaw as root. The env file is only read at startup. This is almost always the tools.exec.security setting. At lower tiers, OpenClaw will quietly block operations without telling you. Set it to full as root and restart. Two likely causes. If tools.exec.host isn’t set to gateway, execution has nowhere to run on a headless VPS. If tools.exec.ask isn’t set to off, commands are waiting for approval that nobody can give. Set both and restart. Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases. Learn more about our products Amit is a Developer Advocate at DigitalOcean 🐳, where he helps developers build and ship better apps on the cloud. Compulsive Seinfeld quoter. LEGO nerd. 🧱 AMA. This textbox defaults to using Markdown to format your answer. You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link! Please complete your information! Reach out to our team for assistance with GPU Droplets, 1-click LLM models, AI Agents, and bare metal GPUs. Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation. Full documentation for every DigitalOcean product. The Wave has everything you need to know about building a business, from raising funding to marketing your product. Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter. New accounts only. By submitting your email you agree to our Privacy Policy Scale up as you grow — whether you're running one virtual machine or ten thousand. Sign up and get $200 in credit for your first 60 days with DigitalOcean.* *This promotional offer applies to new accounts only.