Development Frameworks

Development frameworks are persistent workspaces that create and run a small project for a specific framework. Use one when you want to start from a working application, develop through the browser terminal, or let a coding agent work against a deliberately selected runtime.

Use a framework workspace to:

• Start a web, API, backend, or mobile project from a working framework.
• Use the framework CLI and Git from the browser terminal.
• Grant one coding agent access to the specific framework workspace it needs.
• Test selected private service connections without exposing them publicly.
• Build a Flutter web preview and Android package from one project.
• Validate the project before promoting it to a Git-backed application.

For production, use a Git-backed application deployment. Framework workspaces are optimized for development and testing.

Available Frameworks​

How A Workspace Works​

1. Deploy the framework from the service catalog.
2. Moltern assigns an isolated project directory from the workspace filespace.
3. The service initializes the framework project on first boot.
4. The generated URL opens the running development preview.
5. The service terminal exposes the framework CLI and Git tooling.
6. Selected private services or coding agents can be attached explicitly.
7. Move the project to a Git-backed application when it is ready for production.

Initial dependency installation requires outbound access to the framework's package registries. A failed setup is reported as a failed deployment. Inspect the logs and retry after resolving connectivity or dependency errors.

Build With A Coding Agent​

Coding-agent access is explicit. Deploying a framework does not automatically give every agent access to its files or connected resources.

1. Create or open an authenticated coding agent in the same environment.
2. Open the agent's Resources settings.
3. Add the framework service with the minimum scope needed for the task.
4. Restart the agent when Moltern requests it so the updated policy is applied.
5. Use a private Git repository as the source handoff.
6. Review and test the agent commit in the framework terminal.

The agent policy describes selected resources and connection context. Repository credentials remain separate and should be limited to the repository and time period required for the task.

Synchronize With Private Git​

Every framework runtime includes git, SSH tooling, and the framework toolchain. A typical safe workflow is:

Framework workspace -> private feature branch -> coding agent
Coding agent        -> reviewed commit         -> private feature branch
Framework workspace -> pull and test           -> live preview

Use a repository-scoped deploy key or another short-lived Git credential. Do not place a personal access token in the project, terminal history, screenshots, or committed files. Remove temporary credentials afterward.

Use The Terminal​

1. Open the framework service.
2. Wait for Running status.
3. Open Terminal and choose Open terminal.
4. Change to /workspace/app.
5. Run the framework check from the table.

Do not start another long-running server on the same port as the active development process. See Development Framework Terminal for session behavior, Git safety, and troubleshooting.

Flutter Web And Android​

Flutter uses the same persistent project for both targets:

cd /workspace/app
flutter test
flutter build web
flutter build apk --debug
mkdir -p /workspace/artifacts/flutter
cp build/app/outputs/flutter-apk/app-debug.apk /workspace/artifacts/flutter/app-debug.apk

The public service URL is the web preview. Android builds are produced on the active runtime and can be replaced by a restart. Copy a debug artifact into /workspace/artifacts only when it needs to survive Stop/Start; that persistent copy counts toward workspace storage. Keep release signing keys outside the starter, keep source in Git, and use a controlled release process for signed production packages.

Connect Private Services​

Framework workspaces can connect to selected private databases, caches, queues, or APIs in the same environment.

1. Deploy the private service.
2. Open the framework service settings.
3. Add it under Private Service Connections.
4. Wait for the service update to finish.
5. Open a new terminal session and run a small framework-level connection test.

Access remains scoped to the selected workload. A private service is not made public by attaching it.

Move To An Application​

Move to a Git-backed application when:

• The project has multiple contributors.
• You need review, rollback, or branch history.
• The workload must move between environments.
• You need repeatable builds and production start commands.
• The code is production-critical.
• You need a controlled mobile or web release pipeline.

Related Guides​

• Service Catalog
• Deploy A Catalog Service
• Development Framework Terminal
• Coding Agents
• Private Service Connections
• Create An Application