DEV Community: Alphasec

Stop Hiring, Start Orchestrating: Running an AI Agent Company with Paperclip on Railway

Alphasec — Sat, 16 May 2026 09:02:51 +0000

This is a cross-post from alphasec.io. Original post here.

The idea of a one-person company isn't new. What's new though is the idea of a one-person company where the person isn't doing most of the actual work. AI agents are. You set the direction, define the roles and budgets, and the agents handle the execution — writing, researching, analysing, reporting — on a schedule, without being asked twice. And tools like Paperclip are making it real enough to run today.

What is Paperclip?

Paperclip describes itself as "the human control plane for AI labor." You define a company — give it a mission, a budget, a set of agent personas — and Paperclip runs it. Agents get heartbeats on a schedule, pick up open tasks, call their assigned large language model (LLM), and post results back as issue comments. It's effectively a project management tool where every team member is an AI agent.

Paperclip started as an experiment in running fully autonomous agentic operations at scale — "open-source orchestration for zero-human companies." It's evolving into something broader: a full agent orchestration platform for building companies that run on autonomous agents rather than headcount. The pivot is still in motion, but the core idea is already compelling enough to deploy and explore.

The unit of organisation is a company. Inside a company you have agents (personas with roles, adapters, and heartbeat schedules), projects, and issues (tasks). An agent wakes up when its heartbeat fires, looks at what's assigned to it, does the work, and goes back to sleep. The idea of a pre-built company is quite powerful, and the ecosystem is slowly growing around companies.sh — pre-built company definitions you can import into Paperclip with a single command. Imagine an external penetration testing team, a content agency, or a software development shop, fully staffed with AI agents, importable in seconds.

To make it concrete, here's what a lean content agency could look like:

Agent	Role	Heartbeat
Editor in Chief	Reviews briefs, assigns stories, sets editorial direction	Daily
Research Analyst	Monitors sources, surfaces stories, drafts research notes	Every 6h
Writer	Drafts posts from research notes and briefs	On demand
SEO Analyst	Reviews drafts for keyword coverage and structure	On demand
Publisher	Formats and schedules final output	Daily

Every agent is backed by an LLM of your choice. The Editor in Chief might run on Claude for judgment-heavy decisions; the Research Analyst on Gemini Flash for speed and cost. Each agent has its own adapter, its own system prompt, its own task queue. Paperclip keeps them coordinated.

Deploying Paperclip on Railway

This section covers the deployment of Paperclip on Railway — a managed app hosting platform that handles infrastructure, TLS, and deployments without requiring server management. If you want a VPS approach with a fixed monthly cost, the DigitalOcean guide covers that instead.

Prerequisites: A Railway account, and a valid API key from at least one LLM provider (Anthropic, OpenAI, or Gemini).

Paperclip runs from a custom Dockerfile that wraps the official Paperclip image. An entrypoint.sh script handles first-boot configuration — writing config.json from environment variables, then handing off to pnpm paperclipai run. This approach sidesteps a handful of non-obvious issues: the Paperclip CLI's run command doesn't accept --yes or --no-onboard flags (those belong to onboard), the $meta.source field in config.json only accepts specific enum values (onboard, configure, doctor), and Railway's health check on / returns 403 in authenticated mode — requiring the check to point at /api/health, which also returns 403. Removing the health check entirely and relying on process liveness instead resolves this.

Paperclip supports two database configurations on Railway:

Embedded PostgreSQL (single service) — leave DATABASE_URL unset. Paperclip runs its built-in database. Lower cost (~$5-6/month), suitable for evaluation and small teams. To deploy, launch the Paperclip (Lite) one-click starter template.

External PostgreSQL (two services) — add a Railway Postgres addon and wire DATABASE_URL to ${{Postgres.DATABASE_URL}}. More robust, recommended for production. Runs ~$10-12/month. To deploy, launch the Paperclip one-click starter template.

Post-Deployment Setup and Connection

Railway routes traffic through its edge to port 3100 internally — no port configuration needed in the public URL. Once the service is running, the admin invite URL appears in the service logs. In the Railway dashboard, go to your deployed service → View logs → Deploy logs and search for invite.

=========================================
  Paperclip deployed
=========================================
  URL:        https://paperclip.yourdomain.com
  Invite URL: https://paperclip.yourdomain.com/invite/pcp_bootstrap_...
=========================================

Open the URL to create your admin account through Paperclip's native setup screen. For single-user mode, lock down further registrations by adding PAPERCLIP_AUTH_DISABLE_SIGN_UP=true to service Variables and redeploying.

A couple of adapters work out of the box with environment variables — no interactive login required:

Provider	Adapter in Paperclip	Environment Variable
Anthropic	`claude_local`	`ANTHROPIC_API_KEY`
OpenAI	`opencode_local`	`OPENAI_API_KEY`
Gemini	`opencode_local`	`GEMINI_API_KEY`

For Gemini, select opencode_local as the adapter and choose your model (e.g. gemini-2.5-flash) in the agent settings. The gemini_local adapter requires interactive OAuth and won't work in a Railway container. Similarly, the codex_local adapter needs WebSocket-based authentication that can't be completed headlessly — stick with opencode_local for OpenAI models.

What's Next

The deployment covered here is just the start — Paperclip running cleanly, agents wired up, ready to receive tasks. The real interesting (and fun) part lies in what you build on top of it. The GitHub repo also includes a digitalocean/ folder with a single-script VPS deployment if you prefer a fixed-cost server. I'm fascinated by the companies.sh concept, and I'm exploring a purpose-built agent company - a threat intelligence team that monitors security advisories, extracts IOCs and TTPs, and generates detection rules - as a follow up. If that sounds exciting, it'll be next.

A Developer Built an Open-Source Dropbox on a Dare. Here's How to Self-Host It.

Alphasec — Tue, 21 Apr 2026 16:23:55 +0000

A few weeks ago, @swyx nerd-sniped @zachmeyer into building an open-source Dropbox. Zach took it seriously, and the result is Locker: a self-hostable file storage platform that covers most of what you'd actually use Dropbox or Google Drive for, without the subscription or lock-in.

I came across the thread on X, spent some time getting Locker running on Railway, and figured the deployment notes were worth writing up — especially since the setup has a few non-obvious pieces that trip you up if you're looking to self-host.

What Locker Actually Is

Locker is a Dockerized Next.js application backed by PostgreSQL. The GitHub repo is worth a look — the tech stack is modern and clean: Next.js 16 App Router, tRPC for end-to-end type safety, Drizzle ORM, BetterAuth, and Tailwind CSS, organized as a Turborepo monorepo with pnpm workspaces.

Feature-wise it covers the things you'd actually miss from the commercial alternatives:

File and folder management — upload, rename, move, delete, with a familiar explorer UI
Share links — password protection, expiry dates, and download limits per link
Upload links — let anyone send you files without an account, useful for collecting documents from clients or collaborators
Storage provider agnostic — switch between local disk, AWS S3, Cloudflare R2, or Vercel Blob via a single environment variable, no code changes required
Locker as an S3 bucket — generate Locker API keys and use them in other applications to write data directly to your Locker instance; it speaks S3-compatible protocol
Per-user storage quotas — set limits per user with usage tracking
Workspace teams — invite team members with role-based access and organise files across workspaces
QMD semantic search (optional plugin) — search inside the content of your files, not just filenames
FTS full-text search (optional plugin) — full-text search across your stored documents
Email/password and Google OAuth — authentication handled by BetterAuth, sessions managed server-side
API keys — programmatic access for building integrations and automating workflows
Virtual bash shell — navigate your file tree with ls, cd, find, cat, and grep via a terminal panel; reads your actual stored files lazily from the configured storage provider

The last one is either delightful or unnecessary depending on your personality.

The Storage Provider Thing Is the Key Insight

Most self-hosted file storage tools tie you to a specific backend. Locker doesn't. You set BLOB_STORAGE_PROVIDER in your environment and point it at wherever you want files to live:

Provider	Value	What you need
Local disk	`local`	Just a directory path
AWS S3	`s3`	Access key, secret, region, bucket
Cloudflare R2	`r2`	Account ID, keys, bucket
Vercel Blob	`vercel`	A read/write token

If you already have an S3 bucket, you can point Locker at it and immediately have a UI over your existing data. If you're starting fresh, local disk works out of the box. Switching later is one variable change.

Deploying Locker

Locker is designed to run with Docker Compose — a migrate container runs the database migrations first, then the web container starts once migrations complete. That's the intended flow.

Deploying to Railway takes a bit more work because Railway runs a single container rather than orchestrating multiple services. I spent some time getting this right: the key issue is that migrations need to run before the app starts, and the Dockerfile in the repo builds a Next.js standalone output that doesn't include the migration tooling in the final image by default.

The solution was a custom Dockerfile.railway that copies the migration dependencies into the runner stage and runs them as part of the startup command:

CMD ["sh", "-c", "cd /app/packages/database && pnpm drizzle-kit migrate && cd /app && node apps/web/server.js"]

Drizzle tracks which migrations have already been applied, so this is idempotent — subsequent deploys only apply new migrations and skip the rest.

If you want to skip all of this and just get a running instance, I published a one-click Railway template that handles everything automatically — Postgres, volume for file storage, migrations on startup, and all the required environment variables pre-configured:

What It Looks Like in Practice

After deployment you get a clean file management interface, workspace support for teams, and the ability to generate share links for any file or folder. The virtual bash shell is accessible via a terminal panel and lets you navigate your file tree with standard Unix commands — which turns out to be genuinely useful when you want to script something against your stored files.

Authentication supports email/password out of the box, and you can add Google OAuth by dropping in GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET.

Is It Ready for Production?

For personal use and small teams, maybe yes. For a large organisation relying on it as primary infrastructure, I'd want to see more production mileage first — the project is still relatively young. That said, the tech choices are solid, the codebase is readable, and the maintainer is active.

The hosted version at locker.dev is available if you want to try it before committing to self-hosting.