If you have an index.html, whether written by hand, exported from a tool, or generated by an AI, Quickish turns it into a real website in seconds. Drop a folder and the links inside it just work. When you want more than a static page, add one script tag and you get a backend: a database, file uploads, who's signed in, live updates, and small server functions, all with no keys to manage.

Three ways to publish

What you can build

Start with a one-page site and grow into a real app, all on the same URL:

• A landing page, a résumé, a wedding invite, a link-in-bio, published in seconds.
• A guestbook, a poll, a kanban board, a sprint-retro, using quick.db for storage and quick.realtime for live updates.
• A leaderboard or anything with real relationships, using quick.sql.
• Anything that needs a secret key or trusted logic like a checkout or a contact form, using server functions.

How to read these docs

Getting started is the short path from nothing to a published page. Guides go a step deeper on each capability, in plain language. Workspace covers shared company accounts. The API reference documents every quick.* call precisely, for when you want the exact signature.

From the web

Sign in with Google, then on your dashboard drop a folder (or a .zip or a single .html) onto the drop area. It's live at your space URL right away. Keep an index.html at the root so the page has a homepage.

From the terminal

Install the CLI once, sign in, and publish the current folder:

$ npm i -g quickish
$ quickish login
$ quickish            # publish the current folder

Publish a named sub-page by passing a name: quickish ./site deck serves at /deck/.

By asking an AI

Connect Quickish to ChatGPT or Claude once, then just say “publish this to Quickish” in any chat and your page goes live, assets and all. See Publish with AI for the full setup.

What happens next

Your page gets a URL you can share immediately. From there you can change who can see it, point a custom domain at it, or add a backend to make it interactive.

On a personal account your home page is <you>.quickish.site/, with optional sub-pages at /name/. Publish a sub-page by naming it: quickish ./site deck serves at /deck/. (Work accounts are covered in Workspace accounts & URLs.)

Folders & index.html

Drop a whole folder and the links between files inside it just work, relative paths and all. Keep an index.html at the root so the page has a homepage. If there isn't one, Quickish picks your most recently edited HTML file as the homepage and tells you which.

Single documents render automatically

Publish a single document with no page of its own (a lone PDF, Markdown, text, CSV, or image), and Quickish builds a clean in-browser viewer for it instead of handing over a bare file. A Download button for the original is always one click away.

$ quickish ./resume.pdf     # a single PDF → a real PDF reader at your URL
$ quickish ./notes.md       # Markdown → a styled, readable page

It only kicks in when the document is the whole publish (no index.html). The viewer inherits the page's visibility, so a private PDF stays private. Each viewer loads only what it needs, served first-party.

How many pages render

On the free plan, one HTML file per site renders (its index.html); CSS, JS, and images always load, so single-page sites work perfectly. Paid plans render every HTML page in the folder, so multi-page sites navigate freely. See Plans.

Override it per page in the dashboard, or with a flag on the CLI:

Preview, then promote

When an AI assistant publishes for you (via the Quickish connector), the new app lands as a private preview: only you can see it while you iterate, real backend and all. When it's ready, open the dashboard and hit Promote on the page card to make it live in one click.

Promoting only flips who can view it; the page and its data carry over untouched, because the preview is the page. Publishing from the CLI is direct: it uses the visibility you pass (or the account default), with no preview step.

Remix an app

See a Quickish app you like? Remix it into your own copy. In the dashboard, paste the app's URL and hit Remix, and you get a brand-new private preview under your account (with its own fresh backend) to edit and then promote.

You can remix any public app, or one shared inside your own company. A remix starts with an empty database and never copies the original's live data, unless the source app marks a collection as sample data, in which case those example records come along so your copy isn't blank on first run.

Claude · custom connector

Add Quickish as a connector and sign in once. Then publish from any chat.

1. In Claude, open Settings → Connectors and choose Add custom connector.
2. Set the URL to https://quickish.website/mcp and connect.
3. Sign in with Quickish when prompted, then say “publish this to Quickish” in any conversation.

ChatGPT · custom GPT

Requires ChatGPT Plus. Create a GPT with one action and OAuth; you (and anyone you share it with) sign in once with Quickish, with no tokens to pass around.

1. ChatGPT → Explore GPTs → Create → Configure. Name it Quickish Publisher.
2. Paste instructions telling it to produce one self-contained index.html and call publishToQuickish.
3. Under Actions, add an OpenAPI schema pointing at https://api.quickish.website with a POST /_assistant/publish operation.
4. Set Authentication to OAuth, with the Authorization URL https://quickish.website/oauth/authorize, Token URL https://quickish.website/oauth/token, scope publish.
5. Save and Publish the GPT. Everyone you share it with signs in with their own Quickish account.

The exact instructions and schema to paste are in your dashboard under Settings → Publish with AI.

Coding agents & the CLI

Assistants with a terminal (e.g. Claude Code) can publish for you. Sign in once with quickish login, then ask:

It writes the file, runs quickish (passing --invites when you name people), and hands you the live link.

Advanced · direct API

For your own scripts: grab a publish token in your dashboard under Settings → Publish with AI, then POST a self-contained page. Full details in the HTTP API reference.

$ curl -X POST https://api.quickish.website/_assistant/publish \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "html": "<!doctype html><h1>hi</h1>" }'

Returns { "url": "..." }. Optional fields: page, share (private / public / workspace), invites.

<script src="/quick.js"></script>

That one tag gives you quick.db (a document store), quick.files (uploads), quick.identity() (the signed-in visitor), quick.realtime() (live updates), and quick.cast() (push to a screen from your phone). This page covers the document store; each API has a precise reference too.

Store and read documents

A collection is a named bucket of JSON documents. Create, list, update, remove, and subscribe for live changes:

const tasks = quick.db.collection("tasks");

await tasks.create({ title: "Ship it", done: false });
const all = await tasks.list();
await tasks.update(all[0].id, { done: true });
await tasks.remove(all[0].id);

// live updates over websockets
tasks.subscribe({ onCreate: t => console.log("new task", t) });

Filter, sort & page

list() takes an optional query so you don't have to pull the whole collection:

// open tasks, newest first, 20 at a time
await tasks.list({ where: { done: false }, order: "-created_at", limit: 20 });

// operators: gt / gte / lt / lte / ne / in
await tasks.list({ where: { votes: { gte: 3 }, status: { in: ["open", "wip"] } } });

// page with limit + offset
await tasks.list({ order: "title", limit: 20, offset: 40 });

Filters match top-level fields (max 500 rows per call). Values are always parameters, so a query can never inject anything. Full options in the quick.db reference.

Who can read and write

A collection is owned by the page that creates it. By default it's readable by your page's audience and writable only by you, so a public page can show data without letting visitors change it. Set per-operation rules when you declare it:

// signed-in visitors comment; each edits only their own; you can moderate
quick.db.collection("comments", {
  read: "audience", create: "users",
  update: "author", delete: ["author", "owner"],
});

The full vocabulary of who's who lives in Permissions.

Sample data for remixes

When someone remixes your app, their copy starts empty. Mark a collection as sample data and its documents are seeded into every remix, so the copy works on first run:

// example cards travel with a remix; everything else starts fresh
quick.db.collection("cards", { seed: true });

Only the owner page can set this, and only your own app's data is ever copied (up to 500 records per collection).

Reaching your data from outside

The same collections are reachable off-page (for a script or an AI agent that builds your app) using a data token scoped to one page. See the HTTP API reference. With the Claude connector you don't even need a token; Claude reads and writes through built-in tools.

The vocabulary

Both pages and collections describe access using the same principals, kinds of people relative to the page:

Who can edit a page

Editing a page means re-publishing over it. By default that's owner only: even a company-visible or fully public page can only be changed by you. Open it up for collaborators:

This is independent of who can view the page. Re-publishing never changes who owns a page; adding editors lets people update it, not take it over.

Who can use a collection

A collection gets a policy when you declare it, one rule per operation. Each rule is a principal or a list (allowed if you match any). write is shorthand for create + update + delete.

admins lets you name extra people who count as owner for moderation:

quick.db.collection("comments", {
  read: "audience", create: "users", update: "author",
  delete: ["author", "owner"],
  admins: ["editor@acme.com"],   // can delete anyone's comment
});

A read returns a _mine flag on each record (true when you authored it) so your page can show “edit”/“delete” only where they'll work, without exposing anyone's email.

A static page plus quick.db covers a lot, but everything there runs in the browser where anyone can see it. A function adds trusted JavaScript that runs on the server, so it can call a paid API with a secret key, tally a vote nobody can stuff, or validate input before it touches your data.

browser (public)  →  quick.fn("checkout")  →  your function (secret env, scoped db)  →  quick.db

One file is one function

Drop a file in a functions/ folder next to your page and it becomes a server-side endpoint. The filename is the name:

my-app/
  index.html            # your page (public, served from the edge)
  functions/
    checkout.js         # → quick.fn("checkout")
    lib/
      stripe.js         # NOT a function, a shared module the entrypoints import

Top-level files are entrypoints; anything in a sub-folder is shared code you import. Function source is stored server-side and never shipped to the browser.

The handler

A function exports a default async handler. Return a Response, or just a plain object (sent as JSON) or a string:

// functions/hello.js
export default async function (req, { identity }) {
  const me = identity();                 // the signed-in visitor, or null
  return { hello: me ? me.email : "world" };
}

The handler receives the request and a context object with identity(), env (your secrets), db (a trusted scoped quick.db), and fetch (guarded outbound calls). The full contract is in the server functions reference.

Declare what it needs

A function says what it can touch with a statically-declared config that's read at publish time, so it travels with the file (and with a remix):

// functions/checkout.js
export const config = {
  env: ["STRIPE_SECRET"],                // secret names it may read
  db:  { orders: "write", prices: "read" }, // collections + access
  egress: ["api.stripe.com"],            // hosts it may call out to
};

export default async function (req, { env, db, identity }) {
  const me = identity();
  const order = await db.collection("orders").create({ user: me?.email, items: req.body.items });
  return Response.json({ ok: true, id: order.id });
}

Secrets are set out of band (never in your code or repo), encrypted at rest, and injected only at call time. The injected db is the owner's trusted writer: it can write owner-only collections a public visitor can't, but only the collections you named. Outbound fetch is off until you list hosts in egress.

Call it from your page

const res = await quick.fn("checkout", { items: cart });
if (res.ok) showReceipt(res.id);

// GET with no body:
const status = await quick.fn("status", null, { method: "GET" });

Each invocation runs in an isolated sandbox with comfortable caps (64 MB, 10 s, 20 outbound calls, 1 MB request / 4 MB response) plus a per-account rate ceiling. A function error never breaks your page deploy.

quick.db (documents) is the default for “just store some JSON.” quick.sql is the upgrade for when you actually have relations: a leaderboard, a kanban, anything that outgrows a document store. You get Postgres directly, behind one tagged-template call. No connection string, no setup.

Query from your page

quick.sql is a tagged template that returns the rows. Interpolated values are always bound parameters ($1, $2, …) and never spliced into the SQL, so a hostile value can never inject:

const top = await quick.sql`
  select name, sum(points) as pts
  from scores group by name order by pts desc limit 10`;

const mine = await quick.sql`select * from scores where name = ${user}`;

The browser path is read-only: a single select / with statement, automatically row-capped and time-bounded. Reads follow your page's audience, so a private page's data stays private.

Declare your schema

Schema is declared, not improvised, so it's reproducible and travels with the app. Put ordered *.sql files in a sql/ folder next to your page; they're applied at publish, in filename order, exactly once each:

my-app/
  index.html
  sql/
    001_init.sql
    002_add_index.sql

-- sql/001_init.sql
create table if not exists scores (
  id serial primary key,
  name text not null,
  points int not null default 0,
  created_at timestamptz not null default now()
);

Publish and the migrations run automatically. A re-publish is a no-op unless you add a new file; applied migrations are tracked, so existing ones never re-run.

Writes go through a function

Today, runtime writes come from a server function, your trusted server-side code, so a public visitor can read the leaderboard but only your logic can change it. (Schema and seed data come from your migrations at deploy.) Direct browser insert/update is intentionally not allowed.

How it's isolated

Each site gets its own Postgres schema, owned by a dedicated least-privilege role. A connection for your site can only ever reach your schema, so cross-site access is impossible by construction. It's plain Postgres: use the types, constraints, and functions you already know, and round-trip your data with quickish export.

quick.db or quick.sql?

They're independent: use either, or both, on the same page.

Live updates with quick.realtime

Open a named channel; everyone on the page who joins it sees what you publish, instantly. It's a thin pub/sub bus over websockets:

const room = quick.realtime("lobby");
room.on(msg => console.log("got", msg));
room.publish({ type: "cheer", from: "Tony" });

If you're storing the data anyway, quick.db's subscribe() already pushes create/update/delete events for a collection. Use quick.realtime when you want ephemeral signals (presence, cursors, a buzzer) that don't need to be saved. The channel is scoped to your page, and inherits the page's visibility: a private page's channel is gated at the edge exactly like the page.

Cast to a screen

Put a Quickish page on a TV, projector, or smart display and push content to it from your phone: a link, an announcement, or an image. One call turns the page into a cast target:

<script src="/quick.js"></script>
<script>quick.cast()</script>

Open that page on the big screen and it shows a short pairing code and a link. On your phone, open the same page, enter the code, and you get a remote that pushes to the screen in real time. quick.cast() figures out which side it's on: it's the screen by default, and becomes the remote when the URL carries a code (#qkcast=CODE), so the same page is both.

Because it's built on the realtime bus, casting inherits the page's visibility: a public page is an open display (anyone with the on-screen code can push), while a private/workspace page only lets people the page is shared with connect at all. Want a custom screen or remote? Drive it directly with quick.cast.receive() and quick.cast.connect(). See the quick.cast reference.

A custom domain points your own host at a page you've published. Quickish gets a TLS certificate for it from Let's Encrypt on demand and serves your page there, applying the same access rules as the Quickish URL. Everything keeps working: quick.db, quick.fn, quick.sql, realtime.

Two records, one verification

Binding a domain returns the exact DNS to add: point the host at us, and prove you own it:

A root/apex domain (acme.com) can't be a CNAME, so it uses an A record to the Quickish IP instead, and the bind response tells you which. Don't proxy the record through a CDN (set Cloudflare to “DNS only / grey-cloud”) so the certificate challenge reaches us.

The flow

1. Bind the host to one of your pages. You get back a verification token and the two records above.
2. Add the records at your DNS provider: the CNAME (or A) and the TXT.
3. Verify. We check the TXT over public DNS; once it's there, the domain goes live and the certificate is issued on the first request. DNS can take a few minutes to propagate.

Good to know

• A page can carry several custom domains; one domain belongs to a single Quickish account.
• Managing a page's domains needs the same permission as editing the page (owner, or an editor).
• The .quickish.site, .quickish.space, and .quickish.website URLs keep working alongside your custom domain.
• Removing a domain stops serving it immediately.

Your URL on a work account

On a workspace account you publish to your own page under the company space, keyed by your email handle:

jane@acme.com  →  acme.quickish.space/jane/

A plain quickish with no page name lands there, so you never overwrite a teammate. Add sub-pages under your handle by naming them: quickish ./deck talk → acme.quickish.space/jane/talk/.

Visibility on a work account

The default when you don't choose is company-visible: anyone signed in at your domain can see it. You can still make any page private, invite-only, or fully public per page. The same edit policies apply, so a teammate can be added as an editor without being able to take a page over.

What's shared and what isn't

Everyone in the workspace shares the space and the live org directory, but each person's pages and their data are their own. Reaching another page's collection is a deliberate, paid-plan action; same-page access is always free.

quick.org.sites() (the same data as quick.db.collection("org_sites").list()) returns the org's visible sites with hit counts, kept current as teammates publish. That means a company homepage or directory page never needs updating by hand:

const sites = await quick.org.sites();
// [{ id, name, url, owner, visits, visibility, isHome, updated }, ...]

document.querySelector("#dir").innerHTML = sites
  .map(s => `<a href="${s.url}">${s.name}: ${s.visits} views</a>`)
  .join("");

Members see internal + public sites; the public sees only public ones. Full field list in the quick.org reference.

On free, across sites your latest published page stays live; the rest stay saved and come back the moment you upgrade. Paid serves them all at once.

Publishers & seats

A publisher is anyone in your org who owns a live site. The workspace plan includes 100 publishers and unlimited viewers, so most teams never hit it. Anyone signed in at your domain can publish up to that limit.

Past 100, the workspace admin (whoever verified the domain) decides in the dashboard: either free up a seat, or turn on per-publisher billing at $3/mo ($24/yr) for each publisher beyond 100, optionally capping the total. Until then, publishing is blocked at 100.

<script src="/quick.js"></script>

Almost everything returns a Promise, so use await. All calls are scoped to the page they run on and run through the same access rules as the page itself. Trusted, off-page logic lives in server functions; reaching a page's data over plain HTTP is the HTTP API.

quick.db.collection(name, options?)

Returns a handle to the collection. options is only needed to declare a permission policy or to mark the collection as remix seed data, and only the owner page's declaration counts.

Principals: owner · audience · author · users · workspace · public. See Permissions.

.list(query?)

Returns an array of { id, ...fields }. With no query it returns the collection (capped at 500 rows). The query filters server-side:

await tasks.list({ where: { done: false }, order: "-created_at", limit: 20 });

.create(doc) · .update(id, patch) · .remove(id)

create returns the stored document (with its new id and created_at). update merges the patch into the existing document rather than replacing it. All three are subject to the collection's write policy.

const t = await tasks.create({ title: "Ship it", done: false });
await tasks.update(t.id, { done: true });   // merges, title is untouched
await tasks.remove(t.id);

.subscribe(handlers)

Opens a websocket and calls your handlers as documents change. onCreate and onUpdate receive the document; onDelete receives the id. The return value is a function that closes the subscription.

const off = tasks.subscribe({
  onCreate: t => addRow(t),
  onUpdate: t => patchRow(t),
  onDelete: id => dropRow(id),
});
// later: off();

Reads serve a pre-baked snapshot on first paint (so the page isn't blank), then go live, so your first list() is instant and subsequent ones fetch fresh.

Write SQL inside the template literal. Any ${value} you interpolate becomes a bound parameter ($1, $2, …) and never spliced into the SQL text, so a hostile value can't inject. The call resolves to an array of row objects, and rejects (throws) if the query errors.

const rows = await quick.sql`
  select name, sum(points) as pts
  from scores group by name
  order by pts desc limit 10`;

const mine = await quick.sql`select * from scores where name = ${user}`;

Each site has its own isolated Postgres schema owned by a least-privilege role, so cross-site access is impossible by construction. See the quick.sql guide for schema migrations and the db-vs-sql decision.

Join a named channel and you get two methods: on(cb) registers a callback that fires with each published message (already parsed from JSON), and publish(data) broadcasts data to everyone else on the channel.

const room = quick.realtime("lobby");

room.on(msg => {
  if (msg.type === "cheer") confetti(msg.from);
});

room.publish({ type: "cheer", from: "Tony" });

The channel is scoped to (your page, this channel name) and inherits the page's visibility, so a private page's channel is gated at the edge exactly like the page. For persisted changes, use quick.db's subscribe() instead; for a screen-and-remote experience, use quick.cast (built on this bus).

quick.cast(options?)

The all-in-one entry point. It reads the URL: with no pairing code it sets the page up as the screen (returns a Screen); when the URL has #qkcast=CODE it becomes the remote (returns a Remote). The same page is both.

<script>quick.cast()</script>

quick.cast.receive(options?)

Force the page into screen mode. Shows a standby card with a pairing code and link until a remote pushes content.

const screen = quick.cast.receive({
  title: "Lobby display",
  render(msg, mount) {            // msg = { type, ... } from a remote
    if (msg.type === "text") mount.innerHTML = `<h1>${msg.text}</h1>`;
  },
});

quick.cast.connect(code, options?)

Force the page into remote mode for a given code (defaults to the code in the URL). Renders a phone-friendly panel, and gives you send(msg) to push your own messages and stop() to disconnect.

const remote = quick.cast.connect("AB12");
remote.send({ type: "url", url: "https://example.com/slides" });

Built-in message types: url · image · text · clear. Codes use an unambiguous alphabet (no I/L/O/0/1) and live only for the session. Casting inherits the page's visibility.

quick.files.upload(file)

Pass a File (e.g. from an <input type="file">) or a Blob. It's sent as multipart form data and resolves to a record describing the stored file, including its url. Uploads count against your plan's storage.

<input type="file" id="pick">
<script>
  pick.onchange = async () => {
    const { url } = await quick.files.upload(pick.files[0]);
    await quick.db.collection("photos").create({ url });
  };
</script>

Stored files are served first-party and follow your page's visibility.

quick.identity()

Resolves to the current visitor's identity, or null when no one is signed in. The same identity a server function sees via its identity() helper.

const me = await quick.identity();
if (me) greet(me.email);
else showSignInButton();

Identity is a fact about who's viewing; it doesn't grant access by itself. What a visitor can read or write is decided by your collection policies.

quick.fn(name, body?, options?)

Invokes functions/<name>.js. By default it POSTs body as JSON; the result is parsed as JSON when the function replies with JSON, otherwise returned as text.

const res = await quick.fn("checkout", { items: cart });
if (res.ok) showReceipt(res.id);

// GET with no body
const status = await quick.fn("status", null, { method: "GET" });

quick.org.sites()

Returns the org's visible sites. Identical to quick.db.collection("org_sites").list(). Members see internal + public sites; the public sees only public ones.

const sites = await quick.org.sites();
sites.sort((a, b) => b.visits - a.visits);

See the org directory guide for a full directory page example.

The handler

Export a default async function. Return a Response, or just a plain object (sent as JSON) or a string.

req

ctx

Return helpers mirror the web platform: Response.json(obj), Response.redirect(url), or new Response(body, { status, headers }).

export const config

A statically-declared object, read at publish time, that travels with the file. It's how a function says what it's allowed to touch.

export const config = {
  env: ["STRIPE_SECRET"],
  db:  { orders: "write", prices: "read" },
  egress: ["api.stripe.com"],
};

export default async function (req, { env, db, identity }) {
  const me = identity();
  const order = await db.collection("orders").create({ user: me?.email, items: req.body.items });
  return Response.json({ ok: true, id: order.id });
}

Limits

Per invocation: 64 MB memory, 10 s wall-clock, up to 20 outbound calls, 1 MB request / 4 MB response. Per account: 120/min, 2k/hour, 20k/day. A function error surfaces as a warning and never breaks your page deploy. Call functions from the page with quick.fn; the full walk-through is the Server functions guide.

Data tokens: read & write a page's collections

In your dashboard under Settings → Data tokens, mint a token scoped to one page (read/write or read-only). It goes through the exact same access rules as the in-page SDK and can only ever narrow access, never widen it. Revoke it anytime.

# list documents in a collection
curl -H "Authorization: Bearer $QK_DATA_TOKEN" \
  https://api.quickish.website/_data/db/tasks

# create one
curl -X POST -H "Authorization: Bearer $QK_DATA_TOKEN" \
  -H "Content-Type: application/json" -d '{"title":"Ship it"}' \
  https://api.quickish.website/_data/db/tasks

The same query string as the SDK works here: ?where=<json>&order=-created_at&limit=20. With the Claude connector you don't even need a token; Claude reads and writes through built-in tools.

Publish tokens: put a page online

Grab a publish token in your dashboard under Settings → Publish with AI, then POST a self-contained page:

curl -X POST https://api.quickish.website/_assistant/publish \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "html": "<!doctype html><h1>hi</h1>", "share": "public" }'

Returns { "url": "..." }. Optional fields: page (named sub-page), share (private / public / workspace), invites (emails).

CLI-authenticated endpoints

Some operations are gated to a signed-in CLI session (owner/editor only) while their polished commands land: setting function secrets (POST /_cli/fn-secrets) and binding custom domains (POST /_cli/domains, /_cli/domains/verify).