--- url: /en/docs/workflows/local.md description: >- Edit content in a local Git repository with Sveltia CMS on your dev server — no proxy server required. --- # Local Development Workflow Developers can smoothly work with local Git repositories using Sveltia CMS while running it on a local development server. This allows developers to test and edit content locally without needing to push changes to a remote repository first. ::: warning Breaking changes from Netlify/Decap CMS Our local development workflow eliminates the need for a proxy server. For security and performance reasons, we don’t support `netlify-cms-proxy-server` or `decap-server`. The `local_backend` option is ignored. Read on to learn how to use the new, streamlined workflow. ::: ::: tip Another Option: Test Backend If you want to test the CMS but don’t want to modify local files, you can use the [Test backend](/en/docs/backends/test) instead. It lets you connect to a virtual file system in the browser, so the CMS can be tested without affecting your local files. ::: ## Use Cases * Test Sveltia CMS locally before deploying it to a production environment. * Edit the CMS configuration and see how it affects the CMS behavior. * Make bulk changes to content files and assets and commit them at once. * Work offline without an internet connection. ## Requirements You must have a Git repository initialized in your project directory. You can create a new repository with [`git init`](https://github.com/git-guides/git-init) or clone an existing one. You also need to have a local development server running for your frontend framework (e.g., Astro, Eleventy, Hugo, Next.js) and have installed Sveltia CMS in the project. You need Google Chrome, Microsoft Edge, Brave, or any other Chromium-based browser. The workflow doesn’t work in Firefox, Safari, or other non-Chromium browsers, because this feature relies on the [File System Access API](https://developer.chrome.com/docs/capabilities/web-apis/file-system-access), which is only supported by Chromium-based browsers at this time. Mozilla plans to [implement the API in Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=1909237), but it’s not available yet. We track Firefox support in [issue #38](https://github.com/sveltia/sveltia-cms/issues/38). ### Enabling File System Access API in Brave In the Brave browser, you must manually enable the File System Access API with an experiment flag to take advantage of the local development workflow. 1. Open `brave://flags/#file-system-access-api` in a new browser tab. 2. Click Default (Disabled) next to File System Access API and select Enabled. 3. Relaunch the browser. ## Configuration In your CMS configuration, you must configure one of the supported Git backends: [GitHub](/en/docs/backends/github), [GitLab](/en/docs/backends/gitlab) or [Gitea/Forgejo](/en/docs/backends/gitea-forgejo). No other configuration is required. ::: tip Authentication Not Required If you plan to only work with your local repository, you don’t need to set up authentication with your Git backend. You can use the CMS as a local-only editor UI and commit changes manually using Git. However, if you want to edit content remotely as well, you must set up authentication as described in the backend documentation. ::: ::: tip Repository Name Can Be Arbitrary If you don’t have a remote repository yet, you can use any repository name for the `repo` property in the backend configuration. The CMS doesn’t perform any Git operations, so it doesn’t matter if the repository actually exists or not. However, the backend configuration is still used to store data in the browser’s IndexedDB, which is partitioned by the backend `name` and `repo`. For this purpose, you can use a dummy name, such as `my-name/travel-blog`. ::: ## Workflow The local workflow consists of four main steps: ### 1. Start the development server Launch the local development server for your frontend framework, typically with `npm run dev`, `pnpm dev` or `yarn dev`. ### 2. Edit content In any Chromium-based browser: 1. Open `http://localhost:[port]/admin/index.html`. Replace `[port]` with the actual port number used by your development server. 2. Click “Work with Local Repository” and select the project’s root directory once prompted. 3. Edit content normally using the CMS. All changes are made to local files. ### 3. Preview changes Open the dev site at `http://localhost:[port]/` in any browser to preview the rendered pages. To make further edits, return to the CMS. ### 4. Commit changes With any Git client (CUI or GUI): 1. See if the produced changes (diff) look good. 2. Commit and push the changes if satisfied, or discard them if you’re just testing. ## Tips & Tricks * An indicator is displayed in the Account menu when using the local workflow. * The `localhost` URL: * The port number varies by framework. Check the terminal output from the previous step. For example, if you use Vite-based frameworks like SvelteKit or VitePress, the default port is `5173`. Astro uses `4321`, Eleventy uses `8080`, Hugo uses `1313`, and Jekyll uses `4000`. * The `127.0.0.1` addresses can also be used instead of `localhost`. * If your CMS instance is not located under `/admin/`, use the appropriate path. * It’s recommended to use `index.html` in the URL to make sure the framework treats it as a static file. For example, use `http://localhost:5173/admin/index.html` instead of `http://localhost:5173/admin/`. * Git clients: * You can use any Git client of your choice, including command-line tools (CUI) or graphical user interfaces (GUI). * For CUI, you can use the standard Git commands like `git diff`, `git commit`, and `git push`. * For GUI, popular options include [GitHub Desktop](https://github.com/apps/desktop), [Sourcetree](https://www.sourcetreeapp.com/), [Tower](https://www.git-tower.com/), and [GitKraken](https://www.gitkraken.com/). GitHub Desktop can be used for any repository, not just GitHub-hosted ones. [VS Code](https://code.visualstudio.com/docs/sourcecontrol/overview) also has built-in Git support. * Depending on your framework, you may need to manually rebuild your site or reload the page to reflect the changes you have made. Check your framework’s documentation for details. * You can skip the site preview check if your changes don’t involve any pages. ## Troubleshooting * If you use Astro, don’t include Sveltia CMS in `/src/pages/admin.astro`. If you do, the admin page will be reloaded every time you make a change while working on your local development server. As the [start guide](/en/docs/start#manual-installation) says, the page has to be a static HTML file at `/public/admin/index.html`, where live reload is not applied. * If you get an error saying “not a repository root directory”, make sure you’ve turned the folder into a repository with either a CUI ([`git init`](https://github.com/git-guides/git-init)) or GUI, and the hidden `.git` folder exists. While Sveltia CMS doesn’t read/write files inside the `.git` folder, it checks for the presence of the `.git` folder to verify that the selected folder is the project root and make sure changes made in the CMS can be tracked by Git. * If you’re using Windows Subsystem for Linux (WSL), you may get an error saying “Can’t open this folder because it contains system files.” This is due to a limitation in the browser, and you can try some workarounds mentioned in [this issue](https://github.com/coder/code-server/issues/4646) and [this thread](https://github.com/sveltia/sveltia-cms/discussions/101). ## Limitations The local repository support in Sveltia CMS doesn’t perform any Git operations. You have to manually fetch, pull, commit and push all changes using a Git client. Additionally, you’ll need to reload the CMS after modifying the configuration file or retrieving remote updates. ::: info Future Plans We will explore possibilities to add built-in Git operations in the CMS itself, possibly by integrating [isomorphic-git](https://isomorphic-git.org/), to enable committing changes directly from the CMS interface. The Netlify/Decap CMS proxy server actually has an experimental, undocumented Git mode that create commits locally. For more details, see discussion [#31](https://github.com/sveltia/sveltia-cms/discussions/31). We also plan to use the newly available [File System Observer API](https://developer.chrome.com/blog/file-system-observer) to detect changes and eliminate the need for manual reloads. :::