Status
In private development. Early access by invitation.
Deploying is the step where a pipeline leaves your machine and becomes something your platform runs. In Emolysis it is the last step, never the first: only a pipeline whose lint and golden tests are green can be deployed.
What deploy does
- Check the gate. Emolysis confirms that the pipeline's lint and golden tests are green for its current files. If anything changed since the last run, the tests run again first.
- Check the platform tag. Every generated file carries the platform it was written for. A file written for Databricks does not deploy to Snowflake or Fabric.
- Translate. Pipelines are written in a canonical form. At deploy time, Emolysis translates them into your platform's SQL dialect and renders the platform-specific parts of the template.
- Package. The result is packaged as your platform's native deployment unit.
- Deploy. Emolysis submits the unit to your platform with your credentials. From then on, the pipeline runs on your platform's compute, under your account, on the schedule the unit defines.
Native units per platform
| Platform | What a deploy produces |
|---|---|
| Databricks | A Databricks Asset Bundle (databricks.yml) with its jobs or pipelines |
| Snowflake | SQL that creates or alters tables, streams, tasks and dynamic tables |
| Microsoft Fabric | A PySpark notebook created or updated in your workspace |
Databricks comes first; Snowflake and Fabric are planned; their connectors are tested only on simulated services. On Databricks, the Databricks CLI is not needed: without it, Emolysis creates the same job through the Databricks API. Because the output is the platform's own unit, your team can operate it with the tools it already knows. See Asset Bundle and orchestration.
Deploy from a pull request
If your team reviews changes in GitHub, the pipeline goes to a pull request, and emo check runs lint, golden tests and a cost estimate on it. A reusable GitHub Actions workflow, in preview, runs emo check in your own CI; it needs the emo command line, which is not released yet. The GitHub App is planned. Made required in your branch rules, those checks become the gate for every deploy, and the deploy runs from the merged commit. See GitHub checks.
Cost before you deploy
Each template carries a cost note that says what drives its cost on its platform, such as a full table scan or a warehouse that stays awake. The pull request check adds an estimate for your target platform, so cost is part of the review.
Removing a pipeline
Removing a pipeline deletes what its deploy created on your platform, with its schedule: the Databricks job and its uploaded files, the Snowflake task graph or the Fabric notebook. The tables its runs wrote and the pipeline's files in your project stay. Emolysis asks you first, and it does not remove a pipeline while one of its runs is in progress.
Going back
The deployed unit is a set of files in your repository, so returning to an earlier version means deploying an earlier commit with the same command. Your platform's own history, such as Delta time travel, still covers the data itself.
Moving to another platform
Deploying a pipeline to a different platform is an explicit step. dialect.transpile translates the pipeline's SQL to the target platform, and that platform's template for the same shape is filled and tested again. A /migrate command for the whole step is planned. The migrated files get the new platform's tag.
Where you deploy from
In the app (Deploy), from the command line (emo run pipeline.deploy), and from an editor or coding agent through the MCP server. All three run the same command. See The emo CLI and The MCP server.
If a deploy fails
A deploy can fail even when the golden tests pass, because DuckDB proves the logic and the platform proves the rendering. Most failures are permissions or configuration on the platform side. The error carries the platform's own message in its details. See Troubleshooting for the common cases and Error codes for platform_error.