Recommended Quick Setup
Use this path when you want the shortest practical route from VPS order to a usable Paperclip server workspace. It keeps the first deployment private by default, then lets you choose LAN, tailnet, reverse-proxy or authenticated access deliberately. The full checklist below expands each step.
VPS plan
Choose a plan with 3 CPU cores, 6 GB RAM, 50 GB NVMe storage, unlimited bandwidth, 1 free snapshot, IPv4 + IPv6.
Operating system
Use an Ubuntu VPS or another Linux distribution supported by the selected Paperclip runtime path.
Access method
Connect with SSH keys where possible, use root or sudo access only for setup tasks that need it and restrict exposed ports to the services you intentionally run.
Runtime workflow
Run the Paperclip NPX onboarding path first, confirm loopback access, then choose an explicit bind preset such as LAN or tailnet, or a reviewed reverse-proxy/authenticated access pattern, only when you are ready to expose the service.
Session continuity
Start with the documented Paperclip run command, then add tmux, systemd, Docker Compose, queues or service supervision only where they fit the chosen deployment path.
Safety checkpoint
Take a snapshot before major dependency changes, protect provider keys and repository credentials, keep local_trusted setups off the public internet, test a small workflow and scale the VPS only after measuring real CPU, RAM, storage and runtime activity.
Who This Guide Is For
This page is for users who want Paperclip experiments or team workflows to run from a central VPS environment with observable agents, adapters, heartbeats, tasks and logs.
Teams experimenting with multi-agent control planes
Use a VPS when multiple agents, task state and scheduled wakeups need a shared runtime boundary.
Operators coordinating adapters and heartbeats
Keep adapters, heartbeat schedules, process managers and service logs in one server-side control point.
Builders who need a central dashboard and server logs
Use the VPS as the place to inspect UI state, background processes, run output and troubleshooting evidence.
Developers who want AI agent company experiments isolated from a workstation
PakiWebHost provides the VPS infrastructure. You install, configure, secure, update and operate the software you run on it.
What You Need Before You Start
Before selecting a plan or installing Paperclip, confirm the server access, runtime path, credentials, firewall exposure and recovery routine needed for the deployment.
A Linux VPS suitable for the selected Paperclip quickstart, source-development or container path, with SSH access and root or sudo access ready.
Basic terminal knowledge plus Git, package managers or Docker tooling required by the selected Paperclip setup path.
Install Node.js 20+ and pnpm 9.15+ for NPX or manual source paths, or use Docker for the container path. Add extra runtimes only when connected agents require them.
Use Docker or Docker Compose only when you choose Paperclip's container path; the NPX and manual source paths use Node.js and pnpm instead.
Your own API keys, provider accounts, model access, repositories, configuration, domain, DNS or firewall rules, TLS or private-network plan and a backup/restore routine before production changes.
If you are still choosing infrastructure, compare the matching Paperclip VPS hosting page before choosing a plan.
Choose the Paperclip Runtime Path
Before running commands, decide how Paperclip should be installed, updated, restarted and recovered on the VPS. Use current upstream documentation as the authority for exact versions and flags.
NPX quickstart
Best for a first VPS proof where onboarding creates a local Paperclip instance quickly before you decide whether to bind it to a LAN, tailnet, reverse proxy or authenticated private surface.
Manual Git clone
Best for contributors or advanced teams that need pnpm-based source development and repository-level control.
Docker deployment
Best when you want a containerized Paperclip deployment with explicit volume, port, secret and update handling.
Trusted local mode
Best for loopback-only solo operation behind SSH or a private tunnel. Do not expose local_trusted mode directly to the public internet.
Authenticated mode
Best for LAN, tailnet or public deployments that need login, stricter access checks and a reviewed base URL or reverse-proxy plan.
Recommended VPS Requirements
Minimum starting point for a test environment
Use this to validate the workflow before committing to an always-on deployment. This is a practical VPS starting point, not a guarantee for every agent count or provider workload.
- 2 CPU cores
- 4 GB RAM
- 30 GB NVMe storage
- Ubuntu VPS or another supported Linux server
- Root access
Recommended PakiWebHost starting point
- 3 CPU cores
- 6 GB RAM
- 50 GB NVMe storage
- Unlimited bandwidth
- 1 free snapshot
- IPv4 + IPv6
The recommended starting point gives Paperclip CPU headroom for background tasks and package builds, RAM for dependencies and runtime processes, NVMe storage for agent adapters, heartbeats, companies, UI/API services and run logs, and root access for packages, services and firewall configuration.
Recommended Architecture
The VPS is the runtime layer. You connect over SSH, configure Paperclip and control logs, state and access. For production use, plan authenticated or private networking before exposing it to other users.
You / Operator
You connect over SSH and control the full workflow, configuration, security and updates.
PakiWebHost VPS
Provides the persistent server with storage, networking, root access, snapshots and backups.
Paperclip Runtime
Paperclip server, UI, agents, heartbeats, tasks, database and adapter layer running on the VPS.
External Services
API and model providers, repositories, tools and integrations that you connect and manage.
Why Paperclip Benefits from a VPS
Paperclip benefits from a VPS because the server, UI, adapters, heartbeats, tasks, budgets and logs should be reachable in one controlled place when multiple agents or scheduled wakeups are involved.
Central multi-agent runtime
Keep the Paperclip server, UI, agent state, adapters, database/storage path and background services together in an always-on environment.
Observable heartbeats and tasks
Track wakeups, recurring work, process output, failures and retries from a single server-side log trail.
Clear adapter and credential boundaries
Document adapters, credentials, allowed actions, network access, cost limits and storage paths before connecting real work.
Controlled scaling path
Map the company structure, agents, adapters, credentials, run frequency and storage needs before opening the system to real work. Multi-agent orchestration should be observed with logs and budgets before scaling.
Security Basics for Paperclip on a VPS
- Use SSH keys where possible.
- Disable password login or root login only after a working sudo user and SSH key are verified.
- Use a non-root user where practical.
- Restrict ports; do not expose local_trusted Paperclip mode or port 3100 publicly without reviewed authentication, allowed hosts, public URL and TLS or private-network controls.
- Store secrets in Paperclip config, environment variables or a secret manager with restricted file permissions.
- Avoid committing .env files, config files, local encryption keys, logs or database backups.
- Review Paperclip app logs, UI/API access, agent heartbeat history, adapter activity, budget changes, provider errors and server authentication logs.
- Keep packages updated.
- Snapshot before major Paperclip changes and test restore steps.
- Monitor failed login attempts.
- Rotate exposed or stale provider keys.
- Keep experiments separate from production systems and real customer data.
The server can contain agent adapters, heartbeats, company state, UI/API services, credentials, local encryption keys, database files and run logs. Harden it before production use, and use authenticated mode or private networking before remote users connect.
When This Setup Is Not Necessary
Local testing is enough
You may not need a VPS if you are only testing Paperclip locally, working from one private machine, reviewing a small repository or experimenting without persistent SSH access.
Server management may be unnecessary
This setup is not ideal if you do not want to manage Linux updates, SSH access, firewall rules, disk usage, credentials or repository permissions yourself.
Use a VPS for persistent remote state
Use a VPS when the workspace, company state, logs, tools and multi-agent workflow should stay available in a controlled remote environment.
Ready to run Paperclip on an always-on VPS?
Deploy a Paperclip VPS, keep the first setup private and use this guide with the official Paperclip docs as your review checklist while you prepare the runtime, access controls, backups and logs.
Frequently asked questions
Yes, if the Paperclip release supports the Linux distribution and runtime path you choose, and the deployment mode is configured safely. Use this guide together with the current official documentation.
Not for the VPS runtime pattern described here. This guide focuses on the Paperclip server, React UI, adapters, heartbeats, provider access, company state and run logs. Verify separate hardware needs if you plan local model inference.
No. Bring your own provider accounts, credentials, API keys, model access, repositories and framework configuration.
Start a practical test with a recommended plan, then scale after measuring CPU, RAM, storage and process count for agent adapters, heartbeats, companies, UI/API services, database/storage growth and run logs.
Yes, if Paperclip is run as a server-side process using the documented Paperclip run command and a reviewed service or process-management method. Public access still needs reviewed authentication, allowed hosts and network controls.
Yes. Paperclip documents Docker as an installation method; use it when you want a containerized deployment and can manage the documented compose file, volumes, ports, secrets, public URL, updates and backups deliberately.
No. PakiWebHost provides the VPS infrastructure. You install, configure, secure, update and operate the software you run on it.