Keep the controls your business depends on.
Customer control includes deciding who can do what inside an application, as well as choosing who operates it. Preserving the meaning of supported access rules is a core engineering objective.
Profiles establish a baseline of user permissions. Permission sets add particular grants; groups combine sets, with muting scoped to a group. Roles describe a hierarchy used in record access. Record sharing opens particular records to users and groups. Object permissions govern operations such as reading, creating and deleting records; field access governs which fields a person can read or change.
Those distinctions matter when a query, a form or an automation runs. Importing an access definition is only a starting point: it does not prove equivalent enforcement. We assess the rules, users and execution paths a workload actually needs. Our selected capability notes show the current evidence and limits, including differences between profile, field and sharing coverage.
Let us handle the operations. Keep a choice about who runs them.
The managed-service direction is to take care of deployment, upgrades, monitoring and recovery, so a team can focus on its application. That service is being developed. The pilot is an opportunity to evaluate a specific workload with us; it is not an established production hosting offer.
A usable self-hosting path matters just as much. Our commitment is to document deployment in customer-controlled accounts, the required services, expected costs and the responsibilities that stay with the operator.
The runtime source carries an MIT license, while its dependencies retain their own licenses. Source licensing, access to setup instructions, a tested deployment path and a managed operational service are different things. The source repository is currently private. Local setup documentation and an account-owned deployment recipe exist for participants with source access; a customer cloud deployment has not yet been verified in the published evidence. The setup and deployment status explains that boundary.
Current recipes depend on Cloudflare Workers, Hyperdrive and R2 alongside PostgreSQL. Using accounts you control still involves those providers, their services and their charges. A self-hosting path needs to make those dependencies explicit.
Your exit path matters as much as your onboarding.
Portability should cover the parts that make an application useful: records, supported metadata, files, relationships, and a manifest that identifies the format and runtime version.
The local runtime already has an export and restore format for metadata, live records, deployed source and optional file contents. Local restore keeps record IDs while creating a new org identity and re-keying stored files. Recycle-bin contents are excluded. These are local implementation results, with specific export and restore limits; they do not establish a complete migration or a tested hosted recovery service.
Our goal is to make exports understandable and documented, including version and dependency information. Some supported definitions and records can move through the existing format. Other systems may need conversion, external integrations need reconnection, and unsupported behavior still needs an implementation or a different approach. A pilot should establish the exit path for the selected workload alongside its onboarding plan.
Bring the business behavior you need.
Build independently authored applications and automation on the runtime capabilities that fit your workload. That can mean a focused approval process, a query-backed operational tool, or new business logic built around the metadata and data you choose to provide. A useful pilot can start with one application or workflow; it does not need to move an entire org.
Moving data does not automatically move a managed package’s functionality. Third-party code, dependencies and rights need separate consideration, and managed packages are not assumed to run unchanged. We can identify the behavior a company needs and assess an independently built implementation using the supported runtime contracts.
Understand the service before you depend on it.
We want users to be able to inspect supported behavior and known differences, understand usage allocations, see background-job status, and know how shared work is scheduled. Performance should be measured for defined workloads. Pricing and material policy changes should be explained clearly before a company relies on the service.
These are product commitments guiding development. The current evidence describes bounded runtime contracts and local tests. It does not establish managed-service allocations, scheduling fairness, production performance, pricing, service-level terms or a policy-change notice agreement. Those expectations need to be defined and verified with an actual service offering.
Explore your next org with us.
We’re looking for companies with a specific application or workflow they want more control over. Tell us what it does, how access is managed, and which automation matters most.
Together, we can identify what is supported, what needs work, and whether a pilot makes sense.