How Claude Deploys My Apps to Harper Fabric

I don't run deploy commands anymore. I say "deploy" in a chat with Claude and my code is live on Harper Fabric seconds later. Globally distributed at production scale and ready to be tested.  

This is what vibe coding on Harper actually looks like, not dragging blocks around a GUI, but having a conversation with an AI that understands your project, writes correct code on the first try, and ships it to production when you say the word.

This post walks through exactly how to set it up.

‍

The End Result

Here's what the workflow looks like day-to-day:

Me: "Add a POST endpoint that receives webhooks, validates the signature, and stores the payload"
Claude: Creates resources/Webhook.js with the correct Resource Class pattern, adds signature verification, writes to the database table
Me: "Deploy"
Claude: Runs npm run deploy, confirms the rolling restart completed, app is live

No context switching. No remembering CLI flags. No looking up the Resource Class API for the hundredth time. Claude already knows the project patterns, the deploy pipeline, and the Harper conventions because I told it once in a single file.

The secret to all of this is CLAUDE.md.

‍

CLAUDE.md: The One File That Makes Everything Work

Claude Code reads a CLAUDE.md file from your project root automatically at the start of every session. Think of it as a persistent briefing, everything Claude needs to know about your project so you never have to repeat yourself.

For a Harper Fabric project, this file needs to cover three things:

‍

1. The commands

## Quick Reference

- **Deploy:** `npm run deploy` (uses dotenv-cli + harperdb deploy). Restart takes ~5-8 seconds.
- **Dev:** `npm run dev` (local Harper dev server)
- **Test:** `npm run test` (vitest)
- **Fabric endpoint:** `https://your-app.your-org.harperfabric.com/`

This is why I can just say "deploy" and Claude knows exactly what to run. It reads these commands once and uses them correctly every time.

‍

2. The project structure

## Project Structure 

resources/       # Harper resource classes (HTTP endpoints)
  Webhook.js           # Incoming webhook handler
  HealthCheck.js       # GET /HealthCheck
lib/             # Shared business logic
  config.js            # Config loader
schema.graphql   # Harper table definitions
config.yaml      # Harper app config

When I say "add an analytics endpoint," Claude knows exactly where to put the file, how it connects to the rest of the project, and what conventions to follow. It understands the architecture because the map is right here.

‍

3. The patterns (and the pitfalls)

This is the most important section. Harper Resource Classes have their own API that doesn't look like Express, Fastify, or any other framework. Without explicit guidance, Claude will write Express-style handlers. With it, Claude gets it right on the first try.

## Harper Resource Class API (CRITICAL)

Always use instance methods with `static loadAsInstance = false`.

```javascript
import { Resource } from 'harperdb';

export class MyEndpoint extends Resource {
  static loadAsInstance = false;

  async post(target, data) {
    // target: resource context (pathname, id, search, etc.)
    // data: parsed request body
    const context = this.getContext();
    const headerVal = context.headers.get('x-my-header');
    return { some: 'response' };
  }
}

‍

Common Mistakes (DO NOT)

1. static async post(request) — WRONG. Use instance methods.
2. request.body — WRONG. Body is the data parameter (2nd arg).
3. request.headers — WRONG. Use this.getContext().headers.
4. new Response(...) — WRONG. Throw an error with err.statusCode.
5. First arg to post() is NOT the body — it's the Harper target context.

‍

The "Common Mistakes" section is doing real work here. I added each of these after Claude made the mistake once. Now it never makes them. The `CLAUDE.md` file is a living document — every time Claude gets something wrong, I add the correction, and the problem disappears permanently across all future sessions.

## The One-Time Setup

Before Claude can deploy for you, there's some scaffolding to put in place. You do this once and then forget about it.

### config.yaml

This tells Harper how to load your application:

```yaml
# Load app secrets from CONFIG.env
loadEnv:
  files: 'CONFIG.env'

# Enable HTTP endpoints from resource classes
rest: true

# Define database tables from GraphQL schema
graphqlSchema:
  files: 'schema.graphql'

# Load resource classes as HTTP endpoints
jsResource:
  files: 'resources/*.js'

‍

Every exported Resource class maps directly to a URL path — export Webhook and it's live at /Webhook.

‍

package.json deploy script

{
  "scripts": {
    "deploy": "npx -y dotenv-cli -- harperdb deploy . restart=rolling replicated=true"
  }
}

This one line is what Claude runs when you say "deploy." It loads your Fabric credentials from .env, pushes the code, and does a zero-downtime rolling restart. The engines field in package.json also matters — "harperdb": "^4.4" tells Fabric which Harper version to use.

‍

Fabric authentication

A login.js script collects your Fabric cluster URL, username, and password and saves them to .env:

CLI_TARGET='https://your-app.your-org.harperfabric.com/'
CLI_TARGET_USERNAME='your-username'
CLI_TARGET_PASSWORD='your-password'

Run npm run login once. The Harper CLI picks up these variables automatically on every deploy. Your app secrets (API keys, tokens, etc.) go in a separate CONFIG.env file that ships with the code to Fabric.

Both files are gitignored. Never commit credentials.

‍

What Working With Claude Actually Looks Like

Once the scaffolding and CLAUDE.md are in place, here's how a typical session goes.

Building a new feature:

Me: "Add a GET endpoint that returns aggregate stats from the Events table grouped by day"
Claude: Creates the Resource Class with the correct instance method pattern, queries the table, formats the response
Me: "Deploy"
Claude:Runs npm run deploy — done in 8 seconds

‍

Debugging:

Me: "The POST endpoint is returning 500 — the headers aren't being read correctly"
Claude: Reads the resource, spots request.headers instead of this.getContext().headers, fixes it
Me: "Deploy"

‍
Adding a database table:

Me: "I need an AuditLog table with userId, action, timestamp, and metadata fields"
Claude: Adds the type to schema.graphql, creates a helper in lib/ for writing audit entries, wires it into the existing endpoints
Me: "Deploy"

The pattern is always the same: describe what you want → Claude builds it using the patterns from CLAUDE.md → say "deploy" → it's live. That's the vibe coding loop — you stay in the flow of describing intent while Claude handles implementation and deployment.

‍

Why Harper Fabric Is Ideal for This Workflow

Not every platform works this well with an AI coding agent. Harper Fabric does because of three things:

Single deploy target. There's no separate database to migrate, no API gateway to configure, no static hosting to set up. Database tables, HTTP endpoints, and static files are all defined in the same project and deploy together with one command. When Claude adds a new table to schema.graphql and a new endpoint to resources/, a single deploy handles everything. This is huge — it means Claude never has to coordinate across multiple services or remember a multi-step deploy process.

Convention-based routing. Exported class names become URL paths automatically. Claude doesn't need to configure routes, middleware, or a router — it just names the class and the endpoint exists. This removes an entire category of wiring that Claude would otherwise need to get right.

Fast restarts. Rolling restarts on Fabric take 5-8 seconds. That makes the "change → deploy → test" loop tight enough that it doesn't break your flow. You can iterate with Claude in real-time without waiting around. Describe a feature, deploy, test it, adjust, deploy again — all in under a minute.

The combination of these three things means there's almost no gap between "Claude finished writing the code" and "it's live in production." That tight feedback loop is what makes the whole workflow feel like a conversation instead of a build process.

Getting Started

1. Install Claude Code: npm install -g @anthropic-ai/claude-code
2. Scaffold your Harper project with config.yaml, schema.graphql, package.json, and a resources/ directory
3. Run npm run login to authenticate with your Fabric cluster
4. Write your CLAUDE.md — document the commands, the project structure, and the Resource Class patterns
5. Start Claude Code in your project directory and start building

The CLAUDE.md file will grow as your project grows. Every time Claude makes a mistake or you discover a Harper pattern worth documenting, add it. The file compounds in value — after a few weeks, Claude knows your project as well as you do.

To see what this workflow can produce, I wrote about building a full AI ops assistant in three days using this exact setup.

‍