SeaTable v6.2 Upgrade: Need Help Upgrading?

sha · July 20, 2026, 11:01am

Upgrading to SeaTable v6.2 requires a number of configuration changes that require manual updates to multiple configuration files. The required steps are outlined on the Extra Upgrade Notices page in the admin docs.

Why this change is worth the effort: With v6.2 we are moving settings from configuration files to environment variables. This is a one-time effort that will pay off with every future release:

your configuration lives in one place

is easier to read and to compare against the defaults

future upgrades will require far fewer (if any) manual changes to config files.

In short: a little work now, much less work on every upgrade to come.

If you’re unsure how to apply these changes or would like us to review your configuration, feel free to reply to this thread. We’ll be happy to help you update your deployment and ensure the upgrade goes smoothly.

We’re here to make the upgrade process as straightforward as possible.

As always, please follow our recommendation and always create a full backup of your SeaTable instance before upgrading. Please refer to the admin manual for detailed instructions.

cdb · July 20, 2026, 11:45am

Please take note of the following instructions when replying to this thread:

Describing the Problem/Error/Question:

Please describe your question/issue as precise as possible.
If helpful, you can also provide:

Commands you executed
Error messages (from running interactive commands/in log files/in the web browser)
Screenshots

Providing Configuration Files

Please include the contents of relevant configuration files inside code blocks and use collapsible details elements to prevent unnecessary scrolling.

Remember to remove any sensitive values (e.g. passwords, access tokens) from the configuration files before including them in your posts.

Example

dtable_web_settings.py

# Example
PLUGINS_REPO_ID='...'

Joey42 · July 22, 2026, 12:39pm

Thank you for this thread.

I am evaluating and preparing the update in our self-hosted deployment (current version 6.1.8). For now I have two questions I hope you can answer:

I.
We have a distributed deployment with separate servers for dtable-db (SQL-Server) and dtable-storage (Storage server). Looking at the component configuration for dtable-db ( dtable-db - SeaTable Admin Manual ) the split between dtable-db and dtable-storage is not supported anymore?

Do I just need to enable the dtable-db module in my compose file on the storage server and move the folder seatable/db-data to the storage server’s file system? And in other configs I have to set the variable INNER_DTABLE_DB_URL to the storage server’s IP?

edit: I mixed up the new and old config in my comparison. The new config does support loading from environment.

previous obsolete statement

II.
On our webserver I must move the custom configs of dtable_server_config.json to environement variables?
This is our current config:

dtable_server_config.json

{
    "api_req_max": 6000,
    "api_base_day_max": 250000,
    "rows_api_minute_max": 3840,
    "rows_api_hour_max": 230400,
    "rows_api_max_limit": 50000,
    "operation_rate": "5000/m",
    "redirect_list_row_api": true,
    "dtable_web_service_url": "xyz.de",
    "dtable_storage_server_url": "xyz:6666",
    "dtable_db_service_url": "xyz:7777"
}

When looking inside a temporarily spawned seatable container and reading dtable-server/dist/src/config.js (from my understanding this is the file that handles the import of the env-variables) it doesn’t look like the variable for “operation_rate” being loaded from environment variables anymore? I was looking at this file because not all variables we are using were mentioned as environment variables on the help page and I wanted to verify the variable names ( dtable-server - SeaTable Admin Manual ).

config.js

// old config
// operation rate limit
let operationRate = process.env.OPERATION_RATE || seatableConfig.OPERATION_RATE || config.operation_rate;

// new config
// operation rate limit
let operationRate = config.operation_rate;

Is the operation_rate just another way of indirectly setting the variables OPERATION_RATE_INTERVAL and OPERATION_RATE_LIMIT? Should I instead use these two variables in my new environment variables?

sha · July 22, 2026, 1:44pm

We have a distributed deployment with separate servers for dtable-db (SQL-Server) and dtable-storage (Storage server). Looking at the component configuration for dtable-db ( dtable-db - SeaTable Admin Manual ) the split between dtable-db and dtable-storage is not supported anymore?

Yes, unfortunately, that is no longer supported
dtable-db expects a storage server instance to run inside the same container, available on 127.0.0.1:6666.

Do I just need to enable the dtable-db module in my compose file on the storage server and move the folder seatable/db-data to the storage server’s file system? And in other configs I have to set the variable INNER_DTABLE_DB_URL to the storage server’s IP?

Yes, that should work.

I am assuming that you’re not using the S3 backend for dtable-storage-server? Otherwise you could simply run multiple instances of dtable-storage-server that all point to the same buckets.

Joey42 · July 22, 2026, 1:51pm

Correct, we’re using filesystem as storage backend.

Thanks for the reply.

kiesundreif · July 28, 2026, 9:50am

Hi everyone,

after updating to 6.2, the row-level log entries (the activity/history you see when you open a row) are no longer shown for anything that happened before the upgrade. Changes made since the update are recorded and displayed correctly — it’s only the older history that has disappeared.

Can anyone confirm this? Did I mess something up during the upgrade? And if the old entries still exist somewhere in the backend, is there a way to make them visible again?

Thanks in advance!

sha · July 28, 2026, 10:00am

Sorry to hear this!

Is it possible that you had configured [CLEAN DB] enabled = false inside dtable-events.conf before the upgrade ? This disabled the automatic cleanup of certain database tables to prevent them from growing too large.

Automatic database cleanup was enabled by default for new installations with version v5.3.

If you did not set the new CLEAN_DB_ENABLED environment variable to false when upgrading to v6.2, this is probably the cause. The default retention for the activities table defaults to 30 days, so any entries older than 30 days are automatically cleaned up by dtable-events.

You can check the dtable-events.*.log log files for messages like these to confirm this behavior:

Cleaning "activities" table (older than 30 days)

kiesundreif · July 28, 2026, 12:44pm

Thanks!!!

I think I had [CLEAN DB] enabled = false in dtable-events.conf before the upgrade. Since 6.2 the cleanup started running and removed everything in activities older than 30 days.

i didnt find that in the log files but after the upgrade my backups went approx. 600 MB lighter.

What I’ve done so far:

set CLEAN_DB_KEEP_ACTIVITIES_DAYS=0 in .env and restarted, so nothing else gets removed
pulled the pre-upgrade dtable_db.dump out of a restic snapshot
cut out just the activities table from that dump (~78 MB)

What I’m planning next:

import that extract into a separate database dtable_db_old
compare SHOW CREATE TABLE activities between old and new to check the schema didn’t change in 6.2
INSERT ... SELECT the rows for my base into the live activities, listing columns explicitly without id, and only rows older than the oldest entry currently present so I don’t create duplicates

Does that sound right, or is there something I’m overlooking, so that this doesn’t work or is even dangerous?

I worked this out with Claude, so the reasoning above is partly its analysis of the docs — happy to be corrected if something is off.

sha · July 28, 2026, 1:04pm

That does indeed sound like the now enabled cleanup is the reason.

A word of caution: Setting this variable inside .env is not enough, since the default seatable-server.yml file does not contain the respective variable inside its environment block (otherwise we’d have over 100 environment variables).

So therefore you also need to create an override file (e.g. called custom-seatable-server.yml that contains this variable). This is explained in our admin manual: Customizations - SeaTable Admin Manual

You can use this command to ensure that the variable is available inside the container:

docker exec -it seatable-server bash -c "env | grep CLEAN_DB_KEEP_ACTIVITIES_DAYS"

dtable-events also logs the retention config on startup (inside dtable-events.log):

[2026-07-28 02:00:52] [INFO] clean_db_records_worker.py[line:69] Using the following retention config: RetentionConfig(dtable_snapshot=365, activities=30, operation_log=14, delete_operation_log=30, dtable_db_op_log=30, notifications_usernotification=30, dtable_notifications=30, session_log=30, auto_rules_task_log=30, user_activity_statistics=0, dtable_app_pages_operation_log=14)

The schema of this table did not change between versions 6.1 and 6.2.

Why explicitly without id? Why not simply reuse the old id values?

kiesundreif · July 29, 2026, 9:45am

Thanks — it worked, full row history back!