Development mode

    You can toggle development mode on and off using the Foxx CLI, the or in the service settings tab of the web interface.

    To find out where a service’s active source files are stored, check the service settings in the web interface or the service details when using the Foxx CLI or HTTP API. The root folder for all services can also be set explicitly by overriding the option in the ArangoDB configuration.

    In development mode the service’s source files and manifest will be re-evaluated, and its setup script (if present) re-executed, every time a route of the service is accessed, effectively re-deploying the service on every request. Additionally, error responses generated by Foxx will include stacktraces and when viewed in a browser may include relevant sections of the service code that generated the error.

    To avoid losing your changes, we recommend using a tool like lsyncd to synchronize changes from your local working copy to the service files continuously rather than modifying those files directly. Alternatively you can easily re-deploy your local copy of the service using the .

    • parallel requests may result in race conditions as the setup script may be executed in multiple threads in parallel (outside development mode the setup would only be executed in one thread)

    • if you are serving static files, keep in mind that requests to these files will still result in a re-deployment of the service

    • the service files should be treated as highly volatile as they will be erased if the service is uninstalled/replaced or the database removed

    For these reasons we strongly advise against using development mode on production servers.

    Using development mode in a production cluster is extremely unsafe and highly discouraged.

    Development mode in a cluster applies to each Coordinator individually. Changes to the service’s file system on a single Coordinator will be reflected as usual but only on that single Coordinator. When development mode is disabled on one Coordinator, it will create a new service bundle from the local changes and distribute it across the cluster to the other Coordinators.