11->12 migration config questions

I’m migrating to v12 and am going through all the configuration files. Following config items I have defined in the files are either gone from the docs or have odd default values. Confirmation would be appreciated:

  1. /conf/gunicorn.conf.py defines pids_dir = ‘/opt/seafile/pids’

    • shouldn’t this be someting like ‘/shared/seafile/pids’ under docker installation?
  2. is [notification] / jwt_private_key in /conf/seafile.conf deprecated?

  3. are following configs in /conf/seahub_settings.py deprecated?:
    a) SECRET_KEY
    b) DATABASES
    c) FILE_SERVER_ROOT
    d) ENABLE_THUMBNAIL
    e) COMPRESS_CACHE_BACKEND

  4. is seahub_settings.py.THUMBNAIL_ROOT still valid? What does it default to? Docs claim default value under ‘/haiwen/’, but with docker surely it should be somewhere under /shared?

  5. when migrating from binary installation to docker, should the ccnet/ directory also be migrated over? Asking, as e.g. ccnet/seafile.ini contains a path that doesn’t seem pertinent under the new installation anymore. However there’s ccnet/mykey.peer that contains an RSA key that might or might not be required.

  6. I notice the docs no longer include nginx config blocks for /seafhttp, /media nor the optional /seafdav. Could those be re-added for clarity for future migrators, just in case?

    Note /media was served from now-defunct /seafile-server-latest/seahub/ directory. Is /media route actually deprecated and should be removed from nginx?

  7. when backing up our seafile instance, is there no need to add the new notification server nor seadoc directories to the backup list, assuming we’ve opted into using them?

Based on the Seafile 12.0 upgrade notes and Docker setup documentation, here are the answers to your migration questions:

  1. Gunicorn pids_dir: In a Docker installation, the default path is usually within the container. However, for persistence and ease of management, it is often mapped under /shared/seafile/pids. If you are using the official Docker images, the container handles this internal path, and you generally don’t need to manually redefine it in gunicorn.conf.py unless you have a specific monitoring requirement.

  2. [notification] / jwt_private_key in seafile.conf: Yes, this is deprecated in seafile.conf. In version 12, the notification server is a separate component. You should move the JWT_PRIVATE_KEY to your .env file and remove the [notification] block from seafile.conf. (Reference: Seafile Obsolete Configurations)

  3. seahub_settings.py Deprecations:

    • SECRET_KEY: Still required (standard Django setting).
    • DATABASES: Deprecated in the config file; these settings are now moved to the .env file.
    • FILE_SERVER_ROOT: Deprecated. This is no longer used in v12+ and is calculated automatically from the protocol and hostname in .env.
    • ENABLE_THUMBNAIL: Still valid if you wish to explicitly toggle the feature, though it defaults to True.
    • COMPRESS_CACHE_BACKEND: Deprecated; cache settings are now primarily managed via .env.
  4. THUMBNAIL_ROOT: It is still valid. In Docker, it defaults to a path inside the container that is mapped to your persistent volume, typically /shared/seafile/seahub-data/thumbnail. You shouldn’t need to change this unless you have a custom volume mount.

  5. ccnet/ Directory: In v12, ccnet.conf is completely removed. Most identity and database settings have moved to seafile.conf or .env. When migrating to Docker, you primarily need your databases and the seafile-data directory. The mykey.peer file is generally not required for modern Docker-based installations as the system relies on the database for user and group management.

  6. Nginx Routes (/seafhttp, /media, /seafdav):

    • /seafhttp: This is still used internally for file uploads/downloads, but the unified URL handling in v12 simplifies the Nginx config.
    • /media: In Docker, static files are served by the internal Nginx/Caddy inside the container or via the shared volume. You can usually remove the old manual /media block if you are following the new Docker-based reverse proxy guide.
    • /seafdav: Only required if you enable WebDAV.
  7. Backups: Yes, if you have opted into using the Notification Server or SeaDoc, you should include their respective data volumes (e.g., /opt/notification-data or wherever you mapped them in your docker-compose.yml) in your backup routine to ensure a full recovery is possible.

For a detailed list of what to remove, please see the Summary of obsolete configurations.

(for future googlers regarding point 6 on nginx, see also this response for additional context)

Thanks! Couple of follow-ups:
1.

[notification] / jwt_private_key in seafile.conf: Yes, this is deprecated in seafile.conf. In version 12, the notification server is a separate component. You should /-/remove the [notification] block from seafile.conf

Documentation is conflicting on this. Obsolete config section says the config block is to be removed, whereas notification-server setup config says it’s still needed.

  1. regarding /seafdav nginx path, your other reply here mentions it’s no longer needed, whereas here at point 6 it was said “Only required if you enable WebDAV” – conflicting info.

Regarding your follow-up questions on the v12 migration:

  1. [notification] block in seafile.conf: The “Obsolete Configurations” documentation is the correct reference for the target state of your installation. While individual component setup guides may sometimes show legacy manual configuration methods, the official recommendation for version 12 and 13 (especially in Docker) is to move the JWT_PRIVATE_KEY to your .env file and remove the [notification] block from seafile.conf to avoid ambiguity.

  2. /seafdav Nginx path: The information is complementary rather than strictly conflicting. In the modern Docker-based installation (using the unified Caddy/Nginx proxy provided in the 12.0 templates), many specific paths are handled internally. However, if you are maintaining a manual external Nginx configuration, you only need to include the /seafdav block if you intend to use the WebDAV extension. If you do not use WebDAV, the block is not needed.

You can refer to the Summary of obsolete configurations and the .env configuration guide for the most up-to-date standards.

Because 12.0 is already out of date, we will no longer correct minor errors in the document.

If you find there are errors or conflicts in 13.0 document, just let me know.

1 Like