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 https://www.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
Next.js	Server rendering (SSR, React Server Components)	Yes
	API routes and route handlers	Yes
	Static pages (SSG)	Yes
	Incremental Static Regeneration (ISR)	Yes
	Server Actions	No	Unverified
	Middleware	No	Unverified
	Image optimization (next/image)	No	Unverified
	Composable cache ("use cache")	No	Planned
	Custom storage bindings (KV, D1, R2)	No	Planned
	Native Node modules	No	Cannot run on Workers
	WebAssembly dependencies	No	Cannot run on Workers
Runtime	Native modules (sharp, bcrypt, sqlite3, canvas)	No	Use wasm or WebCrypto equivalents
	child_process, worker_threads, raw sockets	No
	Filesystem writes	No
	Websockets	No	Poll instead
	Long running processes, setInterval	No	Request handlers only, short CPU time per request
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
	Per app Postgres and R2	No	Direction, not shipped
	Secrets, crons, `280 dev`	No	Direction, not shipped

Next.js requires output: "standalone" in next.config.