Local development environment
Development status: Planned — Planned experience, not instructions. The planned developer experience would include a local development environment that behaves like the network, with debugging aids for confidential workloads; the design is being explored. Separately, an experimental local multi-node test setup exists for internal development; it is not this planned environment and is not publicly available. Exact installation commands and released tooling are not yet available, and nothing is publicly available for live use.
Before you read: Future developer experience: what a supported release would add.
Will you be able to develop and debug confidential applications locally before using a network? That is the plan. This preview describes the intended local environment, why confidential workloads need dedicated debugging aids, how the environment would fit a development workflow and its intended limits. It also distinguishes the planned environment from the internal experimental test setup. It names no tools and gives no commands.
Planned experience, not instructions. No local development environment can be obtained or used today.
Why a local environment
- Fast, private iteration. Developing against a shared network is slow and public: every change waits on the network, and every experiment is visible to others. A local environment would allow fast, private iteration on the developer’s own machine.
- Confidential workloads are harder to debug. Confidential workloads are harder to debug than ordinary ones, because the data they process is meant to be protected.
- Synthetic data, not real data. A local environment is intended for development with synthetic data, not for protecting real data.
The planned environment
Status of this section: Planned — the design is being explored; nothing is available.
The planned developer experience would include a local development environment that behaves like the network; the design is being explored.
- On your own machine. It would run on the developer’s own machine and behave like the network in the respects that matter for building and testing applications.
- Work that carries over. Work developed locally is intended to carry over to a network environment once one is offered.
- Closeness not described. How closely the local environment would match a network, and in which respects, is not described.
- Obtaining and starting it. How it would be obtained, started and configured is not described. Exact installation commands and released tooling are not yet available.
Debugging confidential workloads
Status of this section: Planned — the design is being explored; no debugging aid is available.
- Part of the plan. Debugging aids for confidential workloads are part of the planned environment.
- Purpose. Their purpose would be to help developers understand what their confidential workloads are doing during development.
- Content not described. What information they would show, and how, is not described.
- Development only. They are intended for development.
How it would fit a development workflow
Status of this section: Planned — a conditional description of a workflow that cannot be followed today.
Once the environment is released, a development workflow would be expected to include:
- Setting up. Set up the environment as part of getting started; see Getting started once a release exists.
- Building and testing. Build and test against it with synthetic data, using the stage terms on Lifecycle stages used in this documentation and designing for the categories on What can go wrong: failure and error concepts.
- Submitting and following work. Submit and follow work using the planned SDK experience; see Submitting work and retrieving results.
- Moving to a network. Move to a test network, once one is offered, for behaviour that only a network can show; see Networks and environments.
Intended limits
A local environment is not a network.
- What it would not show. It would not show how independent operators reach agreement, how the network behaves under real load or how results become final; see Agreement and finality status.
- Performance is not indicative. Performance and timing observed locally would not indicate network performance.
- Differences would be documented. Known differences between local and network behaviour would be documented with a release.
What exists today
- No public environment. No local development environment is publicly available; see Tools, SDKs and wallet availability.
- An internal test setup. Experimental implementation exists — internal only: an experimental local multi-node test setup exists for the project’s internal development. It is not the planned environment, not a release and not a supported way to develop applications, and its layout, configuration and commands are not published.
- No operator procedures. Production deployment, backup and recovery procedures are not yet specified or published; see Deployment, backup and recovery: what operators would plan for.
Assumptions, trust and limitations
- The planned environment is a development aid. Nothing tested locally is evidence of behaviour on a network.
- General practice: use synthetic data only in development environments.
Not yet available, and how this page will grow
Exact installation commands and released tooling are not yet available. Once released, this page would describe how to obtain, start and use the environment, its known differences from the network and its supported platforms. The real guide is intended to replace this preview at the same address, and the change would be recorded in the Documentation change log.
What this page does not claim
This page does not claim:
- any tool or product name, command or system requirement;
- any degree of fidelity to network behaviour, or any specific debugging feature;
- that local results would predict network behaviour or performance;
- that the internal multi-node test setup is available, supported or a preview of the planned environment.
Anything not stated here as available should be treated as unavailable.
Related pages
- Getting started once a release exists — where setting up the environment fits.
- Submitting work and retrieving results — what you would do in the environment.
- Deployment, backup and recovery: what operators would plan for — the internal multi-node setup and operator concerns.
- Tools, SDKs and wallet availability — what is available today.
- Networks and environments — whether a test network exists.
- Lifecycle stages used in this documentation — stage terms to use when testing.
- What can go wrong: failure and error concepts — failure categories to design for.
Glossary
References
No approved public references yet.
