Roadmap relationship
Outcome
Let users create or import an application from Git, a container image, an uploaded artifact, or local config; detect sensible defaults; preview the generated plan; and keep the result reproducible through typed configuration and API/CLI schemas.
Current gap
ts-cloud has presets and deploy commands but no unified onboarding workflow. Container build commands are partially stubbed, full-stack orchestration is tracked separately, and users must understand low-level config before they can validate source, build, runtime, domain, health, and resource choices together.
User experience
- Use a resumable stepper: source → detection/build → runtime/resources → environment/secrets → domain/health → review/deploy.
- Show detected framework/runtime and the evidence used, with an explicit manual override and a plain-language description of each build strategy.
- Continuously validate inputs, test source/registry access, estimate provider capabilities/cost drivers, and show a generated config diff before mutation.
- Allow save-as-draft, back/forward without data loss, import from existing config, and a post-create checklist.
- Advanced options remain available but do not overwhelm the happy path.
Scope
- Support Dockerfile, buildpack-style auto-detection, static output directory, server command, serverless package, prebuilt OCI image, and drag/drop or local artifact sources.
- Add build context/root, Dockerfile path, target stage, build args, write-only build secrets, install/build/start commands, publish directory, ports, runtime version, architecture, and health check.
- Support private registry connections and image pull credentials with test/rotate/disconnect behavior.
- Handle monorepo root/watch paths, submodules, sparse checkout where safe, and environment-specific overrides.
- Produce one validated application manifest/config patch consumed by the same CLI/API deployment services.
- Link the full-stack ECS/Fargate path in #118 as a supported outcome rather than a separate onboarding concept.
Technical direction
- Create typed source/build/runtime strategy interfaces with detection confidence and provider capability requirements.
- Keep detection pure and fixture-testable; execute builds only after plan confirmation.
- Persist drafts without secret values and serialize final desired state deterministically.
- Represent unsupported combinations as validation errors with alternatives, not late deploy failures.
Safety and operability
- Do not expose build secrets in the config preview, process args, logs, cache keys, or generated artifacts.
- Sandbox/unprivilege detection and uploaded archive inspection; reject path traversal, oversized archives, and unsafe symlinks.
- Production creation/deploy requires explicit target confirmation and displays recurring cost/resource implications.
Acceptance criteria
- A new user can deploy representative Node/Bun, PHP/Laravel, static, Dockerfile, and prebuilt-image examples through the wizard.
- The final plan can be exported and reproduced through CLI/API with no dashboard-only hidden settings.
- Returning to a draft preserves non-secret inputs; missing secrets are clearly requested before deploy.
- Invalid source/build/health/domain combinations fail before any provider resource is created.
Verification
- Detection fixtures for supported frameworks and ambiguous/unsupported projects.
- Archive security, registry auth, config round-trip, draft migration, and secret-redaction tests.
- End-to-end create-and-deploy flows for at least four build strategies.
Non-goals
- Guaranteeing every framework builds without customization.
- Creating a proprietary buildpack ecosystem.
- Making AI-generated configuration a required path.