Docs

280 is a platform which helps humans and agents build secure, internal apps. Professionals across every single domain now have access to AI coding tools, and can quickly vibecode useful protypes for their team.

But anyone building in sensitive domains like finance and health knows, that auth and permissions get complicated fast. They are the difference between a system your team can trust, and one that leaks sensitive data and creates constant internal headaches. Worse, agents rewrite this risky security code from scratch every time, and non-technical teammates have no easy way to review, adjust, or manage who can access what.

This is where 280 comes in. The platform is built agent first, with tools out of the box that let agents deploy, authorize, and permission users at the feature and data level. The human keeps directing features as usual, and can add, edit, and remove fine-grained permissions and secrets in seconds.

Ask your agent

Paste into Claude Code, Cursor, Codex, or your agent of choice.

Fetch 280apps.com/setup.md and push

CLI

For direct control. Every error prints a fix line with the exact command to run next.

280 push

Build identity, deploy, print the live URL. Runs init if new.

--name <slug>: app name on first init (default: package.json name)
--framework next|static: skip detection on first init
--new: force a fresh app instead of linking an existing one

280 init

Detect framework, write .280/config.json. Push does this for you.

--name <slug>: app name (default: package.json name)
--framework next|static: skip detection

280 whoami

Print auth state.

280 login

Authenticate this machine. Prints a link to show your user, then re-run to finish. Never waits.

280 version

Print the CLI version.

280 help

Print every command and flag.

Currently supported

Which stacks, runtime features, and platform capabilities work through a push today.

Stack	Feature	Supported	Notes
Static HTML	Any static site (HTML, CSS, JS, assets)	Yes	Served with SPA fallback to index.html
Next.js	Server rendering (SSR, React Server Components)	Yes
	API routes and route handlers	Yes
	Static pages (SSG)	Yes
	Incremental Static Regeneration (ISR)	Yes	On disk cache is per instance, not durable across restarts
	Server Actions	Yes
	Middleware	Yes
	Image optimization (next/image)	Yes
	Native and WebAssembly dependencies	Yes	Full container, compiled at build time
Other stacks	Any language or framework via a repo root Dockerfile	Yes	Used as is; the app must listen on port 8080
Runtime	Native modules (sharp, bcrypt, sqlite3, canvas)	Yes	Full Node 20 container, built from source
	child_process, worker_threads	Yes
	Filesystem writes	Yes	Local disk only, lost on restart; persist to external storage
	Unrestricted outbound network	No	Default deny; list every host in 280.json egress.allow (others get HTTP 520)
	Raw TCP outbound (e.g. Postgres on :5432)	No	Credential injection is HTTPS only; reach a database over its HTTPS endpoint
	Background work while idle (setInterval, polling loops)	No	A single instance sleeps after about 2 minutes idle; use request handlers
	Websockets	No	Edge proxying of upgrades is unverified; poll instead
Platform	Deploy to a shareable URL	Yes	One verb, `npx -y two80@latest push`
	Device login	Yes	CLI prints a link; user approves once per machine
	Dashboard at 280apps.com	Yes	See, rename, delete apps
	Injected identity SDK (@280/sdk: user, can, scope)	Yes	Gateway signs a verified identity header; the app reads it via @280/sdk
	Feature permissions, sharing grants, route gates	Yes	Two-tier roles in 280.json; owner shares in the dialog; gateway enforces
	General access modes (invited, anyone-at-tenant, public)	Yes	Set in 280.json or the dashboard Share dialog (dashboard wins); public serves anonymous viewers with no sign-in
	Per app Postgres and R2	No	Direction, not shipped
	Secrets, crons, `280 dev`	No	Direction, not shipped

Your app must listen on port 8080 (the platform sets PORT=8080). Next.js and static sites build automatically; any other stack ships a repo root Dockerfile that listens on that port.