PinMe: one-command full-stack deploys from the CLI

The deploy step nobody wants to configure

PinMe targets a specific annoyance: getting a frontend, a backend and a database online without writing deployment configuration by hand. The README frames the project as a zero-config CLI focused on one-command creation and deployment for full-stack projects, and the package description is narrower still: Deploy Your Frontend In a Single Command. Those two statements describe different scopes, and the difference matters when you decide whether to adopt it.

The audience is developers who are happy to run a Node CLI and let a platform provision the Worker and database for them. It is not aimed at teams with an existing Kubernetes setup or a bespoke CI pipeline. The repository ships an AGENTS.md and a CLAUDE.md, a skills/ directory, and the README carries a For AI Agents section, so agent-driven workflows are treated as a first-class use case rather than an afterthought. If you are wiring a coding agent to a deploy step, that section is the part worth reading first.

What pinme create actually provisions

The mechanism is not a thin wrapper around an upload API. According to the README, `pinme create <name>` creates the platform project resources first, then downloads the official Worker project template, writes project metadata into `pinme.toml`, writes backend metadata and frontend config files, installs workspace dependencies, builds the Worker, uploads Worker code and SQL files, builds the frontend and attempts an initial frontend upload.

That ordering explains why the command requires an authenticated session: the platform side exists before the local files do. It also explains the update commands. Because the project is split into three layers, `save` rebuilds everything, while `update-worker`, `update-db` and `update-web` each touch one layer. The README is explicit about what each expects: `update-worker` builds and uploads Worker code, `update-db` uploads `.sql` files from `db/`, and `update-web` builds and uploads `frontend/dist`. Those paths are conventions baked into the CLI, not values you choose.

The static path is separate. `pinme upload` takes a built directory and pushes it, with no project metadata involved. The README lists `dist`, `build`, `out` and `public` as common build directories, and the agent instructions tell a caller to verify the directory contains built assets such as `index.html` before uploading. Domain handling is decided by the string: a domain containing a dot is treated as a DNS domain, one without a dot as a PinMe subdomain, and `--dns` forces DNS mode.

Installing PinMe and shipping a first static build

The prerequisite is Node.js `>= 16.13.0`. Install globally from npm and confirm the binary resolves:

npm install -g pinme
pinme --version

You should see a version string printed. Note that the published package version in package.json is 2.0.11 while the most recent release listed is v2.0.12, so the tag and the manifest do not agree at this point in the repository's history.

Authenticate, then upload an already-built directory. The README uses `pinme upload dist` as the canonical example, and `pinme login` is the recommended authentication path for project commands:

pinme login
pinme upload dist

The CLI uploads the contents of `dist` and prints a URL. If you are running this from an agent or a CI job where an interactive login is not possible, the README gives `set-appkey` as the alternative:

pinme set-appkey <AppKey>
pinme upload dist --domain my-site

A domain without a dot becomes a PinMe subdomain. Passing `example.com` instead would route through DNS mode, and `--dns` forces that path even when the name has no dot. If you want the full three-layer project rather than a static upload, the sequence in the quick start is `pinme create my-app`, then `cd my-app`, then `pinme save` from the directory that contains `pinme.toml`.

Where the zero-config promise stops

The Worker template is the boundary. The README's agent guardrails say not to claim unsupported backend hosting outside the PinMe project template flow. In practice that means PinMe is the wrong tool if you already run a backend elsewhere: it will not take an arbitrary service and put it online. You either adopt the template's shape, or you use `pinme upload` for static assets only and keep your backend where it is.

The second constraint is that project commands are directory-sensitive. The README warns against running `update-*` commands outside a PinMe project root containing `pinme.toml`. There is no flag described for pointing those commands at another directory, so a script that `cd`s to the wrong place fails rather than doing something reasonable.

There is also a size ceiling. The `.env.example` file lists `FILE_SIZE_LIMIT=100 # MB` and `DIRECTORY_SIZE_LIMIT=500 # MB`. Those are the only published numbers for upload limits, they live in an example environment file rather than in the command reference, and the README does not say what happens when an upload exceeds them. If your build output is large, that is the first thing to test rather than assume.

Finally, `pinme delete` removes the platform-side Worker, domain binding and D1 database. The README states that local files remain unchanged. That asymmetry is worth understanding before you run it in a repository you care about.

PinMe against a general-purpose deploy CLI

The closest comparison is a general static host CLI, where you build the site yourself and the tool uploads a directory to a CDN. PinMe's `pinme upload` covers that ground, and the difference there is small: both take a folder and return a URL, and PinMe adds domain binding through `--domain` plus CAR import and export for IPFS-style artifacts, which the README lists under IPFS utilities.

The real divergence is the project workflow. A static host CLI has no opinion about your backend, because it does not deploy one. PinMe's `create` provisions a Worker and a D1 database alongside the frontend, and `save` rebuilds and uploads all three from `npm run build:worker` and `npm run build:frontend`. That is a meaningful reduction in glue code if you were going to assemble those pieces anyway. It is also a commitment: the script names, the `db/` directory and the `frontend/dist` output path are fixed, so a project with a different build layout has to be reshaped to fit before the CLI helps you.

A self-hosted deployment platform is the other alternative, and it inverts the trade. You keep control of the runtime and the data plane, and you take on running the infrastructure. PinMe's value is precisely that it removes that work by putting the resources on its own platform.

Licence, releases and what upgrades cost

PinMe is MIT licensed, and package.json declares `"license": "MIT"` with `publishConfig.access` set to public. MIT is permissive, so the licence itself is not a barrier to commercial use. The thing the licence does not cover is the service: the CLI is open source, but `pinme login` authenticates against a hosted platform that provisions the Worker and the D1 database. Reading the CLI's source tells you how the client behaves, not what the platform guarantees about uptime, data residency or pricing. Nothing in the repository material describes those terms, so treat them as unknown until you find them on the project's own site.

On upgrades, the release history is short and clustered. v2.0.0 and v2.0.4 both landed on 2026-05-12, and v2.0.12 followed on 2026-07-25. The last push to the repository was on 2026-09-12. Two major-version bumps on the same day suggests a period of rapid reshaping rather than a settled API, so pinning a version in CI is a reasonable precaution. The `verify` script in package.json chains lint, typecheck, unit and integration tests, coverage, a build, CLI tests and pack tests, which tells you the maintainers test the published artifact, not just the source. The repository also carries `stryker.config.json` and a `test:mutation` script, so mutation testing is part of the setup.

Editorial conclusion

Adopt PinMe when your project fits the official Worker template and you want one command to build and ship all three layers. Skip it if you need to deploy an existing backend, because the README states that unsupported backend hosting outside the PinMe project template flow should not be claimed. Before committing, run pinme create in a throwaway directory and inspect the generated pinme.toml, the db/ folder and the frontend/dist path it uploads.

Frequently asked questions

Official sources

1. glitternetwork/pinme on GitHub
2. License: MIT
3. Project website
4. README
5. Releases