The first 5 minutes of this video show how to set up a Git repository for a workspace (Git Sync - workspace mode), the rest of the video shows how to use it to deploy to a Prod workspace using GitHub Actions (Git Sync - item mode):

All scripts, flows and apps located in the workspace will be pushed to the Git repository, except the ones that are saved in private user folders (i.e. where the path starts with `u/`, use those with `f/` instead). Filtering out certain sensitive folders from the sync will be available soon.

For finer control, you might want to deploy to a prod workspace from a staging area.

Windmill integration with Git repositories makes it possible to adopt a robust development process for your Windmill scripts, flows and apps.

The process is as follows:

- Users iterate and make their changes in a "staging" Windmill workspace.

- Every time a Windmill App, Flow or Script is deployed to that workspace (via Windmill's UI), Windmill automatically commits it to this repo and creates one branch per app/flow/script.

- On every commit from Windmill, PRs are automatically created via a GitHub Action. Approved GitHub users can review and merge those PRs.

- Every time a PR is merged, another GitHub Action automatically deploys the change to a "production" Windmill workspace.

This gives the flexibility to fully test new Windmill scripts, flows and apps, while having them version-controlled and deployed in an automated way to the production environment.

Deploy to Prod using a Git Workflow is [Cloud and Self-Hosted Enterprise Edition](/pricing) only.

More details at:

<div class="grid grid-cols-2 gap-6 mb-4">

<DocCard

title="Deploy to Prod using a Git Workflow"

description="Windmill integration with Git repositories makes it possible to adopt a robust development process for your Windmill scripts, flows and apps."

href="/docs/advanced/deploy_gh_gl"

/>

</div>

This process can be used in particular for local development with a solid setup:


More details at:

<div class="grid grid-cols-2 gap-6 mb-4">

<DocCard

title="Local Development"

description="Develop from various environments such as your terminal, VS Code, and JetBrains IDEs."

href="/docs/advanced/local_development"

/>

</div>

The first 5 minutes of this video show how to set up a Git repository for a workspace (Git Sync - workspace mode), the rest of the video shows how to use it to deploy to a Prod workspace using GitHub Actions (Git Sync - item mode):

Windmill has [its own integrated development environment](../../code_editor/index.mdx), but you can also develop and run scripts locally, on both [self-hosted](../1_self_host/index.mdx) and cloud instances.

For a more complex and robust local development process, we recommend the following setup with one git repository, a staging and a prod workspace:


It works as follows:

- A git repository with 2 branches: staging and main.

- A staging workspace with [Git Sync](../11_git_sync/index.mdx) workspace mode (all items stored in [folders](../../core_concepts/8_groups_and_folders/index.mdx) are commited to the repo) to staging branch and [Git Sync](../11_git_sync/index.mdx) item mode (any change is committed to an item-specific branch targeting main, with an associated PR, this can be done with GitHub Action [Open PR on Commit](https://github.com/windmill-labs/windmill-sync-example/blob/main/.github/workflows/open-pr-on-commit.yaml)) to main branch.

- A prod workspace with [Git Sync](../11_git_sync/index.mdx) workspace mode to main branch.

- Continuous Integration + [Windmill CLI](../../advanced/3_cli/index.mdx) between Main (resp. Staging) branch and Prod (resp. Staging) workspace to automatically push repo branch changes to workspace. This can be done with GitHub Action [Push on Merge](https://github.com/windmill-labs/windmill-sync-example/blob/main/.github/workflows/push-on-merge.yaml).

With this set up, users can concurrently iterate on both Windmill IDE and code editors locally and commit changes to an item-specific branch targetting main.

Scripts and flow can be editied from any code editor. For VS Code, Windmill has a dedicated [VS Code Extnsion](../../cli_local_dev/1_vscode-extension/index.mdx) that can be found on [VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=windmill-labs.windmill). The extension allows for [UI pre-visualization](../../core_concepts/23_instant_preview/index.mdx), fetching resources, variables, scripts & flows, and testing them. However, these runs and executions are technically carried out from your remote instance.

For iteration, integration with CI/CD and testing purposes you may need to [run a script locally](./run_locally.mdx) that also interacts with Windmill (for example, to retrieve resources). It will allow to integrate Windmill with any testing framework. To do this, you will need to fill out the context variables that would otherwise be filled out by the Windmill runtime for you.

Metadata files are used with the [CLI sync](../11_git_sync/cli_sync.mdx) to push to a Windmill workspace with additional data such as

import DocCard from '@site/src/components/DocCard';

This feature can be referred as [Git Sync](../11_git_sync/index.mdx) - Item mode.

This process can be used in particular for local development with a solid setup:


More details at:

<div class="grid grid-cols-2 gap-6 mb-4">

<DocCard

title="Local Development"

description="Develop from various environments such as your terminal, VS Code, and JetBrains IDEs."

href="/docs/advanced/local_development"

/>

</div>

From the workspace settings, you can set a [git_repository](../../integrations/git_repository.mdx) resource on which the workspace will automatically commit and push scripts, flows and apps to the repository on each [deploy](../../core_concepts/0_draft_and_deploy/index.mdx).

Windmill has a Script Editor with an integrated [Monaco Editor](../code_editor/index.mdx). Only if you prefer, you can also use our [CLI](../advanced/3_cli/index.mdx) and [VS Code](../cli_local_dev/1_vscode-extension/index.mdx), and write your code [concurrently with your team](../core_concepts/7_multiplayer/index.md).

> [1]: Windmill is not just a workflow engine, it is also a function as a service (FaaS) infrastructure where it can run arbitrary scripts in typescript/python/bash/go. Contrary to lambda or gcp cloud functions, we do not need the functions to be pre-packaged and deployed in advance AOT. For TypeScript, we rely on the deno runtime that leverages v8 isolates and the immutable caching capabilities of deno. For Python, we have implemented our own dependency resolver that will override the python virtual path and create a unique virtual environment for that specific script that will respect the lockfile generated at time of saving the script/flow for reproducibility. Given that those are interpreted languages, we pay no performance penalty to interpret that code on demand. So the only limiting factor for task execution is that in the events that dependencies are not cached by the worker, they need to be installed at time of execution. With a limited number of workers, the likelihood of a cache miss is low as soon as one script/workflow is executed more than once. With a large fleet of workers, cache miss increase and hence we have implemented a global caching mechanism that relies on syncing the cache through s3. It is only available in our [enterprise edition](../misc/7_plans_details/index.mdx). With it in place, we run tasks and workflows with 0 overhead versus running the same scripts on bare-metal. You can even leverage hardware acceleration without any additional configuration.

The first 5 minutes of this video show how to set up a Git repository for a workspace (Git Sync - workspace mode), the rest of the video shows how to use it to deploy to a Prod workspace using GitHub Actions (Git Sync - item mode):