bini-deploy scans your project, generates the right hosting configuration for your target provider, and pushes it straight to GitHub — no YAML spelunking, no platform-specific docs to read first.

It's bundled into every Bini.js scaffold and exposed as npm run deploy. This page covers the web hosting providers it supports. For desktop and mobile targets, see Deployment Overview.

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 (the default) when prompted.

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.

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.

Generates:

• vercel.json
• api/index.ts

Cloudflare Workers

API routes run as a Cloudflare Worker.

npm run deploy

Pick web, then cloudflare when prompted.

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.

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:

src/app/api/
├── index.ts          → /api
├── users/
│   ├── index.ts       → /api/users
│   └── [id].ts        → /api/users/:id
└── posts/
    └── [...slug].ts    → /api/posts/*

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's never changed
• Always main — always pushes to main, automatically renaming master if needed
• Remote-ahead recovery — if the remote has commits you don't 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

Troubleshooting

Build fails with Cannot read properties of undefined (reading 'readFile')

Your typescript dependency resolved to TypeScript 7.x, which shipped as a Go-native rewrite without a public compiler API. Some hosting-provider build pipelines break on it. Pin typescript to a ^6.x release in package.json instead of using latest.