# VirtualOrg: an independent runtime for your Org’s Data and Metadata A foundation for faster iteration, on infrastructure you control. October 2026 · Research preview ## Research progress Recorded 2026-10-18T22:53:53.483Z; source b00e32485eab8fbdcad0de8ca13daacb0f41b049, digest sha256:0fb0296b42b2314787e3d22b0233964debd5a7d76e32f989bb7ba92b7e943e11. Visible area buttons show individual percentages; More areas reveals the remaining execution areas. Select Overall or an execution area on the website. Bring the metadata and data you choose to build or export; VirtualOrg focuses on running it. - Overall: 93.8% recorded matches (468/499 research cases); 26 additional local passes; 5 remaining; 1 fully supported. Unique research cases across these execution areas. Bring the metadata and data you choose to build or export; VirtualOrg focuses on running it. - Apex: 100% recorded matches (106/106 research cases); 0 additional local passes; 0 remaining; 0 fully supported. Language execution, control flow and runtime services. Recorded matches apply to bounded contracts and profiles. - SOQL: 100% recorded matches (53/53 research cases); 0 additional local passes; 0 remaining; 0 fully supported. Query execution, filtering, relationships and aggregation across the recorded query contracts. - Field formulas: 100% recorded matches (97/97 research cases); 0 additional local passes; 0 remaining; 0 fully supported. Expression evaluation, functions and typed results. Business validation rules have their own view. - Validation rules: 100% recorded matches (4/4 research cases); 0 additional local passes; 0 remaining; 0 fully supported. Rule evaluation, save-time validation and error placement for metadata you provide. - Flows: 75.8% recorded matches (47/62 research cases); 15 additional local passes; 0 remaining; 0 fully supported. Automation execution, interviews and actions. Local passes still need recorded reference comparisons. - Email: 10% recorded matches (1/10 research cases); 8 additional local passes; 1 remaining; 0 fully supported. Email actions, sender policy and transactional dispatch. Local execution evidence does not establish hosted delivery. - Layouts: 25% recorded matches (1/4 research cases); 1 additional local passes; 2 remaining; 0 fully supported. Layout validation and page assignment; layout API execution remains unfinished. Visual UI parity is outside the headless scope. - APIs: 100% recorded matches (69/69 research cases); 0 additional local passes; 0 remaining; 0 fully supported. REST, Bulk, GraphQL and Tooling request execution, including recorded response and error contracts. - Permissions: 89.2% recorded matches (33/37 research cases); 4 additional local passes; 0 remaining; 1 fully supported. Effective access, permission evaluation and muting. Full support applies only to individually admitted contracts. - Transactions & events: 90% recorded matches (45/50 research cases); 4 additional local passes; 1 remaining; 0 fully supported. Transaction behavior, event delivery and subscription execution under the recorded profiles. - Search: 100% recorded matches (9/9 research cases); 0 additional local passes; 0 remaining; 0 fully supported. SOSL search execution and bounded result contracts. - Platform cache: 71.4% recorded matches (5/7 research cases); 1 additional local passes; 1 remaining; 0 fully supported. Cache execution, partition access and expiry under the recorded contracts. Percentages describe selected execution research cases, not a percentage of a language or platform. Recorded matches are profile-bound; local passes and fully supported contracts are distinct. Overall counts overlapping cases once and excludes object and field inventories. This dated snapshot is not a fresh current-source acceptance run. [Selected-area snapshot data](https://virtualorg.cloud/research-progress.json). [Current source test states and limits](https://virtualorg.cloud/implementation). ## Try the runtime The [browser experiments](https://virtualorg.cloud/#playground-title) run Anonymous Apex with the Rust/Wasm engine, SOQL queries over fictional project records, and field formulas with the runtime evaluator. Edit budget, hours, name and active status, then run a budget runway check, approval policy or query. Choose Anonymous Apex, SOQL query or Field formula to expand an experiment. A compact example picker sits beside Run; Code, Inputs, Results and Scope share tabs. Source and sample data stay in the browser. Query scope is projections, COUNT() and LIMIT; unsupported filters and writes fail explicitly. ## Company pilot program We're looking for companies interested in exploring independent execution of their own org metadata and data. [Apply to the pilot program](https://virtualorg.cloud/pilot) with a brief use case and the capabilities you need. Applications are reviewed individually; org access is arranged separately. ## Abstract VirtualOrg helps teams run their own org metadata and data in an independent environment. Teams provide the material they want to work with; the runtime uses supported definitions to execute business logic, query records, and present an application on infrastructure the team can control. The project is focused on carrying forward the value of work accumulated over years: data models, configurations, formulas, validation rules and application logic. The current experimental implementation runs selected Apex programs and SOQL queries, with metadata-driven layouts and application navigation. ## 1. Purpose Our goal is not to replicate Salesforce. We do not present VirtualOrg as a replacement for it. We are exploring an independent execution environment for metadata and data that users provide and are authorized to use. An org reflects years of decisions about how a business works. Migrating that work into a new environment should preserve its useful structure and give the team room to develop it further. VirtualOrg aims to make that transition possible for supported application definitions, with clear boundaries around what can run today. The motivation is flexibility: shorter experimentation cycles, new integrations, and more choice about where an application runs. Teams should be able to build on their own configurations and business logic as their needs change. ## 2. Metadata as an application model An org contains more than records. Object definitions describe a domain. Formulas express relationships. Validation rules capture constraints. Layouts and navigation determine how people encounter the application. VirtualOrg reads selected metadata definitions and uses them to construct an application model. Its local implementation includes record operations, formula evaluation, validation rules, permissions, metadata-driven forms and layouts, and navigation between applications and objects. These pieces make metadata useful as executable application structure. Portability remains a question of the particular application. The current implementation covers a bounded set of behaviors; an imported application can require adaptation when it depends on an unimplemented feature or an external service. ## 3. Code, queries and data The runtime executes selected Apex programs against its own application state. SOQL provides a metadata-aware way to query that state, with application permissions and record visibility evaluated by the runtime. PostgreSQL provides the underlying database. Operating that database also makes SQL available for authorized database work, such as inspection and analysis. SQL access is governed by database permissions; it is a separate interface from the application's SOQL API. Keeping execution and storage under the operator's control makes it possible to explore new workflows around existing business logic and data. It also makes the runtime's behavior something that can be inspected, tested and improved directly. ## 4. Building with open-source foundations The application interface uses established open-source components, including the published [Salesforce Lightning Design System](https://github.com/salesforce-ux/design-system) for selected interface foundations, with its applicable attribution and notices retained. The design system supplies presentation resources. VirtualOrg supplies its own application logic and execution environment. The [design-system documentation](https://developer.salesforce.com/docs/platform/lwc/guide/create-components-css-slds) describes these presentation resources and their use. ## 5. An ongoing experiment Working local scenarios provide a starting point. Recorded comparisons and implementation tests help identify what works, what differs, and what still needs to be built. They are evidence for specific behaviors, rather than a claim that every existing org can run unchanged. The company pilot program is for teams that want to explore running their own org metadata and data independently. [Tell us about your use case](/pilot) so we can review the capabilities it needs and discuss a focused pilot. Org access is arranged separately; sign-in and org creation remain inactive while the hosted database and account services are being connected. The longer-term goal is straightforward: let people keep building on the application knowledge they already have, while gaining the flexibility to take it somewhere new. ## Contact Interested in a company pilot? [Apply to the pilot program](/pilot). For other questions, write to [hello@virtualorg.cloud](mailto:hello@virtualorg.cloud). [Join pilot program](https://virtualorg.cloud/pilot) · [Org login](https://login.vorg.live). Hosted sign-in and org creation remain inactive.