UNVERIFIEDSchema 0.1Version 0.1.2

Guided Notebook

Deploy OpenClaw + n8n on a VPS

Prepare a security-conscious Ubuntu VPS foundation for n8n and a future verified OpenClaw installation, using DownDoggy as the worked example without creating provider lock-in.

This Lab is currently educational and does not execute code or external actions.

Difficulty: Starter
Estimated time: 60 minutes
Cost band: Low
Length: 16 Steps

Business outcome

Create a recoverable, privately bound VPS foundation for an n8n workflow service while preserving a clear verification gate before OpenClaw installation.

A named sudo operator can open a separate SSH session before root access is closed
Docker and Compose report usable versions for the named operator
The n8n Compose configuration validates and binds its host port to localhost
No credential value is stored in the Lab definition or Compose example
OpenClaw is not installed from an invented or unreviewed command

Compatibility paths

Coding approaches

ManualCodexClaude CodeCursorGrok Build

Deployment targets

VpsUbuntu

The Lab is provider-independent at the content and tool level. Commands target a compatible Ubuntu host; provider-specific console and firewall controls require translation.

Journey

FoundationsBuildRun SafelyDeploy

Review the starting point

Confirm the host, recovery path, and limits before changing the VPS.

Instructions

Review the prerequisites and record non-secret host facts. Do not paste credential values into this Lab or a model prompt.

Intended result

Prepare an Ubuntu VPS for a privately bound n8n service and a future verified OpenClaw installation. DownDoggy is the worked example, but the workflow should transfer to a compatible Ubuntu VPS.

Before you start

Keep a provider recovery path available.
Use only approved SSH credentials.
Plan where secrets will live outside this public definition.
Expect provider firewall and snapshot controls to differ.

Lab Step 2of 16

Architecture

Map the private service architecture

Keep host administration, workflow control, and agent runtime boundaries visible.

Instructions

Trace which component accepts network traffic, which component stores workflow state, and where a future public HTTPS boundary would sit.

The operator enters through SSH. Docker runs application services, but it does not replace host security. n8n binds to localhost in this example. OpenClaw remains a future private service until upstream installation and gateway behavior are verified.

Human

Named operator

Review and perform each manual action through an approved SSH session.

Deployment

Ubuntu host

Enforce operating-system users, network policy, storage, and service lifecycle.

Workflow Control

n8n container

Run reviewed workflows on a localhost-bound application port.

Agent Runtime

Future OpenClaw gateway

Remain uninstalled until a verified source and private gateway configuration are available.

Relationships

operatorhost

Administer through approved SSH access.

hostworkflow

Run n8n through Docker with localhost binding.

hostgateway

Reserve a private boundary for future verified installation.

Lab Step 3of 16

Security Stop

Limit initial privileged access

Use root only for the bounded bootstrap and preserve a recovery path.

Instructions

Before connecting, confirm the host fingerprint through an approved provider channel and plan to test a second non-root session before changing root or SSH policy.

Stop and reviewSecurity Stop

Pause and understand the boundary before continuing.

Data visible

Server IP address
SSH host fingerprint
Operator username

Read capabilities

Read host identity and operating-system status

Write capabilities

Bootstrap a named sudo user
Update installed packages

Credential types

ssh-private-key
sudo-password

Affected systems

DownDoggy or compatible VPS

Logging considerations

Do not record private keys, passwords, or full SSH configuration
Redact public IP addresses before sharing terminal output

Emergency stop / rollback

Keep the provider recovery console and the initial working session available. Stop if the fingerprint is unexpected or a second login cannot be established.

Risk notes

A mistaken SSH target can disclose credentials
Closing the only working session before testing the new account can lock out the operator

Human approval required: Yes

Lab Step 4of 16

Terminal

Connect to the VPS

Open the initial SSH session using the server address from the provider console.

Instructions

Replace the documented host placeholder locally, compare the presented host fingerprint with the provider record, and continue only when it matches.

Command shown for reference

ssh root@YOUR_SERVER_IP_LOCATION

Expected result: SSH presents the expected host identity and opens the initial root shell on the intended VPS.

Studio only copies this command. Run it manually from your own terminal after replacing the placeholder and verifying the host.

Lab Step 5of 16

Terminal

Update Ubuntu

Apply available package metadata and upgrades before adding the application runtime.

Instructions

Review the upgrade list and provider maintenance expectations. A kernel or critical library upgrade may require a separately planned reboot.

Command shown for reference

apt update
apt list --upgradable
apt upgrade

Expected result: Ubuntu shows the available upgrades for review and applies only the package transaction the operator confirms.

These commands change the VPS. Review the listed packages and recovery options before confirming the upgrade prompt.

Lab Step 6of 16

Terminal

Create a non-root sudo operator

Move routine administration away from the root account.

Instructions

Choose the intended username, replace the example if needed, and follow the interactive password prompts without copying the password into notes or prompts.

Command shown for reference

adduser doggydish
usermod -aG sudo doggydish

Expected result: Ubuntu creates the doggydish account and adds it to the sudo group.

Run during the bounded root bootstrap. Review the username and interactive prompts before making the change.

Lab Step 7of 16

Test

Validate the new operator session

Prove non-root access before changing any existing access path.

Instructions

In a separate terminal, configure the approved SSH key for the named user through a reviewed method, open a new session, and confirm a bounded sudo command succeeds. Keep the original session open until this passes.

Validation mode: Manual
Expected result: The new session identifies the named non-root user and sudo can perform the approved check.

Validation instructions

Open a second SSH session as the named operator, confirm the username with whoami, and use sudo for a non-destructive identity check.

Regression criteria

Do not disable or close the working root path before this check passes
Do not copy a private key or password into the Lab
Do not continue when the second session fails

Local check status Not official verification evidence

Not checked

Lab Step 8of 16

Terminal

Install Docker and Compose

Install Ubuntu-packaged Docker components and grant the named operator intentional access.

Instructions

Run as the named sudo operator. Confirm these package names exist for the selected supported Ubuntu release; if they do not, stop and use the current official Docker instructions rather than a copied convenience script.

Command shown for reference

sudo apt update
sudo apt install -y docker.io docker-compose-v2
sudo systemctl enable --now docker
sudo usermod -aG docker "$USER"

Expected result: Docker starts, Compose is installed, and the named operator is queued for Docker group membership after a fresh login.

Studio does not run these commands. Verify package availability for the selected Ubuntu release and sign out and back in before testing group membership.

Lab Step 9of 16

Security Stop

Review Docker and network authority

Treat Docker access and published ports as privileged decisions.

Instructions

Pause before starting containers. Review group membership, image provenance, secret delivery, host-port bindings, provider firewall rules, and recovery for the n8n data volume.

Stop and reviewSecurity Stop

Pause and understand the boundary before continuing.

Data visible

Container images and configuration
n8n workflow and execution metadata
Host port bindings

Read capabilities

Inspect Docker configuration, containers, logs, and volumes

Write capabilities

Start privileged host containers
Publish host ports
Modify persistent n8n data

Credential types

n8n-encryption-key

Affected systems

Container image registry
VPS network boundary

Logging considerations

Do not place credentials in Compose files committed to source control
Review container logs before using real workflow or customer data

Emergency stop / rollback

Use docker compose down to stop only this project without deleting volumes. Preserve the n8n data volume before any destructive reset or host rebuild.

Risk notes

Docker group members can obtain root-equivalent control of the host
A 0.0.0.0 host binding can create unintended public exposure
Unpinned or unreviewed images can change without notice

Human approval required: Yes

Lab Step 10of 16

Code

Prepare the n8n Compose configuration

Create a localhost-bound, persistent n8n service definition.

Instructions

Copy this configuration into /opt/n8n/compose.yaml, replace the image-tag placeholder with a reviewed pinned n8n version, and supply secrets through protected runtime configuration outside this public Lab.

Provide a reviewable Compose starting point that preserves n8n data and avoids binding the application port to every host interface.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:REPLACE_WITH_REVIEWED_PINNED_TAG
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    volumes:
      - n8n_data:/home/node/.n8n
    environment:
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true

volumes:
  n8n_data:

Copying does not create or start a service. Replace the placeholder and review current n8n requirements before using this configuration.

Lab Step 11of 16

Prompt

Review the deployment assumptions

Use a provider-independent prompt to inspect a redacted configuration plan.

Instructions

Paste only a redacted Compose configuration and non-secret exposure plan. Remove credential values, tokens, private keys, real hostnames, IP addresses, and customer data before using any model or coding assistant.

Help a developer review the planned n8n boundary without granting a model execution or deployment authority.

Editable prompt browser-local only

Edits stay in this browser.

`{{redacted-compose}}`

The Compose content with secrets, addresses, and private identifiers removed.

Example: A localhost-bound n8n service using a named volume

`{{access-boundary}}`

A non-secret explanation of how an operator intends to reach n8n.

Example: SSH tunnel during validation

`{{recovery-plan}}`

A non-secret summary of volume backup and host recovery steps.

Example: Stop Compose, back up the named volume, retain a provider snapshot

Lab Step 12of 16

Terminal

Validate and start n8n

Render the Compose plan before starting the reviewed container.

Instructions

Create the application directory, save the reviewed compose.yaml there, run the configuration check first, and stop if the output contains the placeholder or an unexpected public port binding.

Command shown for reference

sudo install -d -m 0750 -o "$USER" -g "$USER" /opt/n8n
cd /opt/n8n
docker compose config
docker compose up -d
docker compose ps

Expected result: Compose validates the reviewed file, starts the n8n container, and reports the service with a 127.0.0.1 host binding.

The configuration check and service start occur only when you run these commands manually. Stop if the rendered plan is unexpected.

Lab Step 13of 16

Test

Verify n8n locally

Confirm service health and private binding before considering external access.

Instructions

Inspect the Compose status and host listener, then access n8n only through an approved private path such as a local SSH tunnel during this validation.

Validation mode: Manual
Expected result: n8n responds through the private path and no direct public listener exists for port 5678.

Validation instructions

Check docker compose ps, inspect the host listener for port 5678, and open the n8n setup UI through the approved private access path. Do not create a public route for this test.

Regression criteria

The container is not repeatedly restarting
The host binding remains 127.0.0.1:5678
Logs do not disclose secret values

Local check status Not official verification evidence

Not checked

Lab Step 14of 16

Learn

Stop at the OpenClaw verification gap

Do not turn the legacy placeholder into an invented installation command.

Instructions

Locate and review an authoritative, versioned OpenClaw source and its current private-gateway instructions outside this Lab before creating a future verified revision.

Verification required

The legacy Build Portal contains only # OpenClaw install command goes here. This definition intentionally provides no OpenClaw installation command. A later revision must cite a reviewed upstream source, pin or record the tested version, confirm gateway binding behavior, and pass an end-to-end verification before this Lab can claim an OpenClaw deployment.

Lab Step 15of 16

Security Stop

Review exposure, secrets, and recovery

Keep n8n and any future OpenClaw gateway private until protection is designed.

Instructions

Before adding any DNS, firewall opening, reverse proxy, or gateway configuration, review authentication, TLS, least-privilege secrets, data retention, logging, backups, and an emergency stop.

Stop and reviewSecurity Stop

Pause and understand the boundary before continuing.

Data visible

n8n workflows and execution data
Future OpenClaw prompts, configuration, and tool output

Read capabilities

Read private workflow and future agent state

Write capabilities

Change workflows and future agent configuration
Potentially call external systems only after separate authorization

Credential types

n8n-encryption-key
service-authentication-secret

Affected systems

VPS network boundary
Any future reverse proxy or identity provider
Any future workflow integration

Logging considerations

Do not log credentials, complete prompts, private workflow data, or user-supplied secrets
Set an intentional n8n execution-data retention policy

Emergency stop / rollback

Remove or disable only the reviewed public route, stop the affected Compose project without deleting volumes, revoke any exposed credential, and restore from a tested backup when required.

Risk notes

A public application port without authentication can expose control and data
Firewall rules alone do not supply application authentication
Future agent tools require separate authorization and cannot inherit blanket Docker or host access

Human approval required: Yes

Lab Step 16of 16

Test

Record the safe stopping point

Distinguish the verified n8n foundation from the unverified OpenClaw remainder.

Instructions

Review each success criterion and record only what you personally validated. Mark the overall Lab complete only as a local reading aid, not as DoggyDish verification evidence.

Validation mode: Manual
Expected result: The VPS has a validated private n8n foundation, while OpenClaw installation remains an explicit unverified follow-up rather than a claimed success.

Validation instructions

Confirm the named-user login, Docker and Compose versions, stable n8n container state, localhost-only listener, protected secret plan, volume recovery plan, and the unresolved OpenClaw installation gate.

Regression criteria

Do not claim DoggyDish verification from browser-local completion
Do not expose n8n or a future gateway directly to the Internet
Do not replace the missing OpenClaw command with an uncited instruction
Do not scale infrastructure without measured need

Local check status Not official verification evidence

Not checked