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 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 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 project is being prepared for a private hosted pilot. 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 the research or a future pilot? Write to hello@virtualorg.cloud.