What the dashboard is best at
- Interactive workflow authoring in Workflow Studio.
- Visual inspection of generated flow, code, validation, preview, and deploy state.
- Managing connections and custom providers with an operator-friendly UI.
- Inspecting deployment records and logs without leaving the browser.
What the CLI is best at
- Project initialization and local startup.
- Local-only workflow loops before you commit to cloud deployment.
- Provider and connection management from scripts or CI.
- Cloud deployment flows that need to run outside the browser.
- Teams that want terminal-first operations but still benefit from the same GTMship control plane.
gtmship dev
gtmship providers list
gtmship connections connect hubspot
gtmship validate
# deploy later when ready
gtmship deploy --provider awsLocal-only run loop
The simplest way to use GTMship is entirely local: start the dev environment, connect providers, author the workflow, validate it, and preview it in the dashboard. No cloud account is required until the workflow needs to stay live outside your machine.
Start local services
gtmship dev brings up the local development environment so the dashboard and auth flow can work against the same project.
Validate before deploy
Use the local loop to connect systems, inspect the generated workflow, run validation, and preview sample events before introducing cloud infrastructure.
Promote later
When the workflow needs stable webhooks, schedules, shared access, or production traffic handling, keep the same project and add a deploy step.
How they work together
The dashboard and CLI are not separate products. They operate on the same project configuration, auth service, connection data, workflow artifacts, and deployment records. You can connect a system in one surface and keep working from the other without changing tools or state stores.
Shared connections
Providers and credentials stay available no matter which surface you used to create them.
Shared workflow state
Workflow source, preview context, and deployment state remain tied to the same project.
Shared deployment records
Build metadata, bindings, and release status stay visible whether you kicked off the deploy from the browser or the terminal.
Shared inspection flow
Logs, runtime details, and troubleshooting context remain part of the same project story instead of splitting into separate tool silos.
Common handoff patterns
Bootstrap in CLI, refine in dashboard
Teams often initialize projects and start services from the terminal, then switch to the dashboard for interactive workflow authoring.
Connect visually, automate later
Operators can set up providers and credentials in the UI first, then rely on CLI commands once the flow needs to become repeatable.
Inspect in dashboard, rerun in CLI
A failed preview or deploy can be inspected visually, then reproduced or retried from scripts once the root cause is understood.
Use dashboard for exploration, CLI for CI
The browser is usually the faster place to understand state. The terminal is the better fit when the same operations need to run in automation.
Recommended operating pattern
- Use the CLI to initialize a project and open local services.
- Use the dashboard for interactive authoring, validation, preview, and inspection.
- Use either surface for deployment depending on whether the task is exploratory or automated.
- Return to the CLI when you want repeatable commands or CI integration.