Installation

Already included in every Bini.js scaffold. To add it to an existing project:

$ npm install --save-dev bini-deploy

Supported Providers

How it works

1. Scan - scans src/app/api/ for route files
2. Generate - creates the platform-specific entry file and config
3. Clean - removes leftover entry files, config, and directories from any previously selected platform, including when switching to Node or a native platform
4. Push - commits and pushes everything to your GitHub repository
5. Deploy - your hosting provider deploys automatically from GitHub

Usage

Every Bini.js scaffold already has this wired into package.json, so deploying is just:

$ npm run deploy

This runs bini-deploy interactively - it prompts you to pick a platform (web, windows, macos, linux, android, ios) and, if you choose web, a hosting provider (node, netlify, vercel, cloudflare, deno).

For scripts and CI, skip the prompts with flags:

$ npx bini-deploy --platform web --hosting vercel --repo https://github.com/you/your-app --yes

Node.js

The default hosting choice. bini-server reads your API handlers directly from src/app/api/ at request time - no build step, no generated entry file.

$ npm run deploy

Pick web, then Node.js (the default) when prompted:

? Select hosting provider:
> Node.js (default - bini-server)
Netlify
Vercel
Cloudflare Workers
Deno Deploy
 
↑↓ navigate • ⏎ select

Works out of the box on Railway, Render, Fly.io, or a bare VPS with pm2. See Production Server for the full runtime reference.

Netlify

API routes run as Netlify Edge Functions.

$ npm run deploy

Pick web, then Netlify when prompted:

? Select hosting provider:
Node.js (default - bini-server)
> Netlify
Vercel
Cloudflare Workers
Deno Deploy
 
↑↓ navigate • ⏎ select

Generates:

• netlify.toml
• netlify/edge-functions/api.ts

[build]
  command = "vite build"
  publish = "dist"

[[edge_functions]]
  path = "/api/*"
  function = "api"

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

Vercel

API routes run on Vercel's Node.js Runtime.

$ npm run deploy

Pick web, then Vercel when prompted:

? Select hosting provider:
Node.js (default - bini-server)
Netlify
> Vercel
Cloudflare Workers
Deno Deploy
 
↑↓ navigate • ⏎ select

Generates:

• vercel.json
• api/index.ts

Cloudflare Workers

API routes run as a Cloudflare Worker.

$ npm run deploy

Pick web, then Cloudflare when prompted:

? Select hosting provider:
Node.js (default - bini-server)
Netlify
Vercel
> Cloudflare Workers
Deno Deploy
 
↑↓ navigate • ⏎ select

Generates:

• wrangler.toml
• worker.ts

Or deploy manually with Wrangler once the entry file exists:

$ npx wrangler deploy

Deno Deploy

API routes run on Deno.

$ npm run deploy

Pick web, then Deno when prompted:

? Select hosting provider:
Node.js (default - bini-server)
Netlify
Vercel
Cloudflare Workers
> Deno Deploy
 
↑↓ navigate • ⏎ select

Generates:

• server/index.ts

In the Deno Deploy dashboard, set:

• Entrypoint: server/index.ts
• Runtime: Dynamic App

API Routes & Hono

Every provider mounts the same file-based routes from src/app/api/, dynamic segments and catch-alls included:

Each route exports a default handler that accepts a Request and returns a Response (or a JSON-serializable value):

export default async function handler(req: Request) {
  const id = new URL(req.url).pathname.split('/').pop();
  return { id, name: 'Ada Lovelace' };
}

Imports from hono are detected automatically and mounted as a full Hono app instead:

import { Hono } from 'hono';

const app = new Hono();

app.get('/', (c) => c.json({ message: 'Hello from Hono!' }));
app.post('/', async (c) => {
  const body = await c.req.json();
  return c.json({ received: body });
});

export default app;

Automatic CORS

API routes get permissive CORS headers out of the box on every non-Node hosting adapter - Netlify, Vercel, Cloudflare, and Deno - so your frontend can call them without extra setup.

Git Push Behavior

• Existing remote - used without modification
• New projects - the provided URL is added as origin
• No remote updates - once a remote is set, it is never changed
• Always main - always pushes to main, automatically renaming master if needed
• Remote-ahead recovery - if the remote has commits you do not have locally (e.g. GitHub auto-created a README), bini-deploy fetches and merges automatically with --allow-unrelated-histories -X ours, keeping your local version of any file that exists on both sides. A warning prints before the merge runs; a real conflict stops the process and prints manual recovery steps

Requirements