Bitfield Docs

Bitfield products are not only pages. They run through runtime identities that send request bytes to Bitfield, with local state, account-owned access, and product packages that should keep working as your idea changes.

In this page, runtime identity includes cloud and local shapes. A laptop, server, worker, kiosk, or CI runner can all count when they actually send request bytes to Bitfield during the billing window.You start with a laptop and phone. Then a friend tests it. Then ten customers use it. The product shape should not change just because the device count grows.

Account

The customer creates an account and receives access through the account portal.

→

Device

Each device or runtime identity sends request bytes to Bitfield when it needs runtime access.

→

Product

The product reads local Bitfield state and uses packages/surfaces/targets.

Deployment questions

Question	Why it matters	Page
How does the user get a key?	The product cannot run without account access	Get your key
How many devices can try it first?	Trial shape affects first customer experience	Trials and billing
What will actually be charged?	Runtime/device units are identities that send Bitfield request bytes, not visitors, page views, projects, or packages	What you pay for
Where does local state live?	Users need to understand ownership and no-hand-edit boundaries	Local state
Which package runs the feature?	Product behavior should stay package-shaped	Package authoring
Which surface appears first?	The first visible result sells the product path	App surfaces

Rollout shape

Start by proving the product moment on one device. Then invite more devices without changing the product architecture:

Keep the package file stable.
Keep the surface read/request contract stable.
Keep the shell placement contract stable.
Let account/device access decide who can run it.

Adding devices should change access and activation, not the feature boundaries you already built.

Hosted and static output

A hosted product can send Bitfield request bytes from a server. That server runtime identity can count for the billing window.A public static page is different. Visitors reading ordinary hosted output send no Bitfield request bytes. Keep marketing pages, docs pages, pricing pages, and other public read-only pages static when they do not need live Bitfield data or Bitfield requests.That is not a workaround. It is the clean deployment shape. Use Bitfield where the product needs Bitfield, and do not pay for runtime where static output is enough.

Common failures

Symptom	Cause	Fix
Works on one machine only	Local state and account activation were not part of the build path	Add the key/device path to the launch checklist
Users hand-edit local state	Docs or UI did not explain ownership	Link to local-state boundaries and expose product controls
Every device needs a different feature build	Product package and shell placement are tangled	Separate package, surface, target, and shell concerns
Public visitors look like runtime units	Static pages and live Runtime Kit surfaces were mixed together	Keep public read-only pages static and use Runtime Kit only where Bitfield request bytes are needed

Use Get your key for the account path, read What you pay for for the billing model, then return to Build with Bitfield to choose the next product seam.

Build a product

Activation

Device and deployment shape

Deployment questions

Rollout shape

Hosted and static output

Common failures

Next

​Deployment questions

​Rollout shape

​Hosted and static output

​Common failures

​Next

Deployment questions

Rollout shape

Hosted and static output

Common failures

Next