tiny3.31 KB
View saved version →
---
name: tiny
description: >-
Build and deploy apps to Tiniest Cloud, which gives every app sign-in, per-user storage,
realtime, push notifications, scheduled jobs and an LLM with no keys and no backend. Use when
building or changing an app hosted on Tiniest Cloud, or when you see tiny.db, tiny.ai, or
tiny.rules.json.
---
# Building for Tiniest Cloud
Tiniest Cloud puts apps, websites, dashboards and reports online. Each one gets sign-in,
per-user storage, realtime rooms, push notifications, scheduled jobs, backend functions and a
language model, with no keys anywhere and no server to set up.
## Call `tiny_guide` first
**Before writing or changing any app that will be deployed here, call the `tiny_guide` tool.**
It returns the current SDK reference, the limits and the patterns that matter, then names the
guide's other sections; call it again with `section` for each one the build uses (`fetch` to
call another service's API, `jobs` for scheduled work, `functions` for server code). This file
deliberately does not repeat any of it. The platform gains features,
and a copy pasted into a plugin listing would keep teaching an old API long after the real one
moved on, producing apps that deploy cleanly and then fail in the browser.
So: `tiny_guide`, then build, then `deploy`.
**Before designing, call `tiny_guide` with a `topic`** — `design`, `app`, `website`,
`dashboard`, `presentation` or `form` — for how that kind of thing should look: a direction for
the product and its industry, palette, type, motion, light and dark, and a checklist. When the
person has design standards of their own (a design system, components, a brand guide, an app to
match), those come first and the playbook only fills what they leave open.
## What never changes
These four hold regardless of which version of the SDK is current, and they are the ones an
agent gets wrong when it treats this like ordinary web hosting:
- **Build the frontend with the SDK.** Plain HTML, CSS and JavaScript, or a framework's build output
(a React or Astro project's `dist/`), with `index.html` at the top level of what you deploy. With a shell, a new one starts from
`npm create tiniest-cloud@latest <folder>` (add `-- --template site` for a website).
- **Do not write a login flow.** Sign-in belongs to the platform. The SDK tells you who the
visitor is; there are no passwords, sessions or tokens for the app to handle.
- **Do not use `localStorage` for anything that matters.** It is per-browser and per-device,
so the same person loses their data on their phone. Storage in the SDK follows the account.
- **Do not add a server of your own or call your own API.** There is no origin to call. Logic
users must not be able to change runs as a backend function: a file in the deployed
`_functions/` folder (`public/_functions/` in the starters), called from the page with
`tiny.call`. Anything that needs a secret goes through a connection the app's owner declares,
so the key never reaches the page or the function's code.
## Deploying
The server cannot read your disk. Read the files yourself and pass their contents to `deploy`.
Every deploy is a new immutable version, and earlier versions stay restorable with `rollback`.
If a deploy reports that an app uses `localStorage` or calls its own backend, `modernize_app`
converts it to the platform's own storage and sign-in.
tiny-design24.3 KB
View saved version →
---
name: tiny-design
description: How apps, websites, dashboards, presentations and forms built for Tiniest Cloud should look and feel — a direction chosen for the product and its industry, palette and type, layout and balance, motion, light and dark, and the checks before calling it done. Use when designing, building or restyling anything to deploy on Tiniest Cloud. Where the person has design standards of their own (a design system, components, a brand guide, an app to match), those come first and this fills only what they leave open; with none, follow it all.
---
# Designing for Tiniest Cloud
## Design — make it look made for its job
**Their standards come first.** When the person has design standards of their own — a design
system, a folder of components, a brand guide, a Figma file, an app or site to match — those
decide, and this section and the design playbooks only fill what theirs leave open. Don't
restyle their components to taste, swap their fonts or colours for ones suggested here, or
"fix" a choice of theirs that this section would call a giveaway (their brand may well use
Inter, or a gradient). Where something of theirs would hurt the people using the app — text too
faint to read, a control too small to tap — build it as specified and tell them, rather than
quietly changing it. When they give nothing of their own ("build me an app for…"), all of the
rest applies.
An app that works but looks like every other starter is not finished. Before the first screen,
decide what this one should feel like — and write it down: a short `DESIGN.md` at the project
root with who it is for, the feel in three words, the palette, the type and how much motion (or,
with their standards, where those live and what they settle).
Hold every screen to it, and read it first when you change the app later (for an app built on
Tiniest Cloud it is kept with the source `get_app_source` returns).
**Start from what it is and who uses it.** Read the request for its scope (a tool used every
day, a page read once, a dashboard glanced at), its audience and its field, and follow that
field's conventions:
- Money, health, legal, B2B: calm and trustworthy — quiet neutrals, one confident accent,
dense data that lines up, tabular numbers.
- Food, shops, hospitality, events: warm and inviting — richer colour, big imagery, softer shapes.
- Creative, personal, community: expressive — a bolder palette or a display typeface, more motion.
- Kids, games, fitness: energetic — saturated colour, large targets, playful feedback.
- Internal and admin tools: quiet and fast — compact, keyboard-friendly, colour only for status.
A brand, colours or an example the person names always win over these.
**Give it its own palette — theirs if they have one, never the default grey.** Set the theme once, in the CSS
variables (the app starter's `src/index.css`, `:root` and `.dark`): `--primary` is the one
accent (main actions, links, selection), `--muted` and `--accent` are quiet surfaces, plus
`--destructive`, `--ring`, `--chart-1`…`--chart-5` and `--radius`, in both themes. Components
read those tokens; never hard-code a hex colour or `bg-blue-500` in a component, or the dark
theme breaks and the palette stops being one decision. Use colour on purpose: most of a screen
is neutral, and colour marks what to do (the primary action), what is selected, status
(success, warning, error) and the one number that matters — roughly 60% background, 30%
surfaces and text, 10% accent. Keep contrast: 4.5:1 for body text, 3:1 for large text and icons,
in both themes.
**What gives generated UI away — don't** (unless their standards ask for it): the same default font for everything (Inter, system
UI) instead of one chosen for the job; purple-to-blue gradients, glassy cards and glowing blobs
as decoration; a card around everything, cards inside cards; an icon in a rounded square above
every heading, emoji standing in for icons; grey text on a coloured background, pure black and
untintedPreview of the first 4,000 characters. Read full instructions →
Referenced files: 5 — file references are metadata, not package contents.
