Skip to main content

Development Framework Starters

Development framework starters are catalog services that create a small runnable project for a specific framework. They are useful when you want a quick sandbox before creating a repository or deploying a full application.

Use starters for:

  • Trying a framework inside a Moltern environment.
  • Prototyping a small API, dashboard, or backend service.
  • Testing private service connections from a development workload.
  • Demonstrating a runtime to a teammate.
  • Validating resource sizing before moving the project into Git.

For production, use a Git-backed application deployment. Starter services are intentionally optimized for experimentation and development.

Moltern FastAPI framework starter service overview

Available Starters​

StarterGood ForUseful Terminal Check
FastAPI StarterPython APIs, webhooks, async endpoints, and internal services.python --version
Django StarterPython web apps, admin tools, APIs, and server-rendered products.python manage.py check
Go StarterFast HTTP APIs, small backend services, and worker endpoints.go version
Laravel StarterPHP web apps, APIs, internal tools, and product backends.php artisan --version
Next.js StarterReact apps, SSR dashboards, portals, and hybrid frontend experiences.node --version
Node Express StarterREST APIs, webhooks, microservices, and Node.js HTTP services.node --version
Phoenix StarterElixir realtime apps, APIs, LiveView products, and resilient services.mix --version
Rails StarterRuby on Rails web apps, admin panels, and product backends.bin/rails --version
Spring Boot StarterJava APIs, JVM business services, and backend workloads.mvn --version

How They Work​

  1. Deploy the starter from the service catalog.
  2. Moltern creates a workspace volume for the generated project files.
  3. The service initializes the framework project on first boot.
  4. The generated URL opens the running starter app.
  5. Supported development services can use terminal access from the service detail page.
  6. When the prototype is ready for production, move the code into Git and deploy it as an application.

If a package registry is unavailable during first boot, starters show an offline fallback page instead of staying down. Restart the service later to retry the framework setup.

Terminal Workflow​

Use the terminal when you need to inspect the generated workspace or run framework commands.

Moltern framework starter terminal tab

  1. Open the starter service.
  2. Wait for Running status.
  3. Open Terminal.
  4. Click Open terminal.
  5. Run a small command such as ls, pwd, or the framework check from the table above.

Most generated projects live under:

/workspace/app

Do not start another long-running web server from the terminal on the same port as the running starter. Use the terminal for short commands, setup checks, and debugging.

For terminal availability, reconnect behavior, and troubleshooting, see Development Service Terminal.

Connecting To Private Services​

Development starters can connect to private services in the same environment when the service supports runtime variables.

Typical flow:

  1. Deploy the private database, cache, queue, or API service.
  2. Open the starter service settings.
  3. Use Private Service Connections to connect the target service.
  4. Wait for the service update to finish.
  5. Open a new terminal session or restart the app process so the variables are available.

Use this pattern to test database queries, cache access, or internal API calls without exposing private services publicly.

First-Boot Fallback​

Some starters download framework dependencies during first boot. If the dependency registry is unavailable, Moltern keeps the service reachable with an offline fallback page.

When this happens:

  1. Open the service logs to confirm the setup step that failed.
  2. Open the terminal if the service is running.
  3. Inspect the workspace for generated files or fallback notes.
  4. Restart the service later to retry setup.

The fallback page is for development resilience. For production, move working code into Git and deploy it as an application.

When To Use Git Instead​

Move to a Git-backed application when:

  • The project has multiple contributors.
  • You need review, rollback, or branch history.
  • The service should be promoted across environments.
  • The workload needs repeatable builds.
  • The code is production-critical.

Starter services are development surfaces. Applications are the production deployment path.