Skip to main content
Version: 5.16

File Synchronization

There are two types of file synchronzation processes:

  • on-demand file sync using devspace sync and
  • file synchronization during development mode using devspace dev.

Start On-Demand File Sync#

To establish an on-demand file synchronization between your local computer and the containers running inside Kubernetes, use the following command:

devspace sync # common flags: --local-path=./ --container-path=/app --no-watch --config=./devspace.yaml

Learn more about the devspace sync command.

Configure File Sync#

If you want to start file synchronization every time you run devspace dev, you can configure it within devspace.yaml.

Learn more about configuring file synchronization using devspace.yaml.


Troubleshooting#

Check sync.log#

DevSpace logs all sync activity in .devspace/logs/sync.log. Check this file to get more detailed error information.

Verbose Sync#

DevSpace provides the flag --verbose-sync to print additional information while running devspace dev:

devspace dev --verbose-sync

For an even cleaner output (sync-only logs, without container logs), deploy your application using devspace dev once, then abort the dev mode and start a standalone sync process using the --verbose flag:

devspace sync --config=devspace.yaml --verbose

Ignore .git/#

The sync can fail when files are constantly being changed while they are being synchronized. DevSpace will retry failing sync attempts but for folder such as .git/ which contain continuously changing information and files which may be locked by the IDE, we recommmend to ignore them via the excludePaths option in devspace.yaml.

File Permissions#

Without file write permission, the sync will not be able to work. If you start your containers (in production) using a different user than root and this user does not have sufficient permissions to read and write certain files, you can:

* You can achieve this by:

  • Adding a USER statement in your Dockerfile: This is especially recommended when you are using multi-stage builds because you can add the USER statement for your development/build stage and add another USER statement to your production stage. Then, control the build target using the options.target option for Docker and kaniko builds and define a profile for removing the build stage for production deployments.
  • Setting runAsUser and runAsGroup to 0 within the securityContext of your Kubernetes pods.