Deployment and operations
Version upgrades and migration
Back up data, upgrade versions, and complete the required migration steps.
Routine upgrades update the images. Crossing certain versions also requires migrating vector data or adjusting text collation rules. Back up data and check the migration requirements for the relevant versions before upgrading.
Prerequisites
| Item | Requirement |
|---|---|
| Known current version | Bottom-left avatar → “System settings” → “About” on the left → System version |
| Chosen target version | The delivered Compose file uses :latest; to upgrade to a specific version, pin the image tag to that version number |
| Maintenance window | The service is unavailable during the upgrade |
| Completed backups | See below |
Stop application writes before backing up. This is required to restore the state before the upgrade. The commands below use this page's Compose service names and leave PostgreSQL running to complete the backup:
docker compose stop asktable
docker compose exec -T asktable-pg pg_dump -U asktable -d asktable -Fc > backup-asktable.dump
tar -czf backup-asktable-data.tar.gz asktable_dataIf Workbook is enabled, back it up separately with a different filename:
docker compose exec -T asktable-pg pg_dump -U asktable -d asktable_workbook -Fc > backup-asktable-workbook.dumpAlso record the original image version and store the deployment configuration securely. Confirm backups are readable and test restoring a copy. Copying a running PostgreSQL data directory is not a database backup. Complete upgrade requirements before starting the new version.
Steps
Check requirements for the version range
Read the sections below that apply to your upgrade range and prepare environment variables, database images, and other requirements before starting the target version.
Pull new images
docker compose pullStop services and recreate containers
docker compose down
docker compose up -dContainers run database schema migrations at startup; you do not need to run SQL manually.
Confirm the version and migration results
Bottom-left avatar → “System settings” → “About” on the left → System version should show the target version; docker compose logs asktable should contain no migration errors.
Complete functional verification
Check login, project permissions, historical content, and an actual query according to the relevant migration section before ending the maintenance window.
Upgrade to the Organization version
This section applies when upgrading from a version that has not introduced organizations. Private deployment assigns existing active users and projects to one default organization. The earliest-created system administrator becomes the organization Owner, and other users become Members. Public and private projects move into the organization scope; IDs, API Keys, conversations, and analysis canvases of normal valid projects are retained.
Migration removes invalid historical data, including projects without a valid owner and their associated resources, and orphaned memberships. It also deletes old global authentication configuration keys. These removals cannot be reversed by switching back to an old image. Back up the database and business files before upgrading, and inspect migration results on a backup copy.
Check administrators, project owners, and backups
Confirm that the old instance has at least one system administrator and that all existing projects have valid owners. If users exist but there is no system administrator, private deployment migration stops rather than choosing an organization Owner arbitrarily. Restore the correct administrative identity in the old version first.
Follow this page's backup steps to stop application writes and back up the main database, the Workbook database if enabled, and asktable_data. Record the original image version. Migration removes ownerless projects; repair owner relationships before upgrading if those projects must be retained.
Fix deployment mode and Region
Keep AT_DEPLOY_MODE=local for private deployment and explicitly set AT_REGION: cn or AT_REGION: global in the main service environment. Region defaults to cn; later changes require identity data migration. Local always uses email as the account identifier.
Migrate login and email configuration
Convert the old version's Google, GitHub, WeChat, email login, SMTP, and SMS settings that are still needed into environment variables. Fill OAuth ID/Secret and SMS URL/Key in pairs; see Deployment authentication configuration. Old database authentication configuration keys and the mandatory-phone-number switch are no longer configuration sources.
Existing Local WeCom/WPS integrations migrate into the default organization. Migration reports an error if existing enterprise configuration is incomplete; complete the original configuration first and retain a backup. After upgrading, the organization Owner/Admin manages these integrations under Profile → Organization → Enterprise integrations.
Start the target version
After confirming image tags and environment configuration, pull the target images and start them for online deployment. For offline deployment, use installation scripts and offline packages from the same release; see Private deployment (Docker).
docker compose pull
docker compose up -d
docker compose logs --since=10m asktableDatabase migration runs before the application starts. If it fails, save the error logs and identify the cause; do not skip migration and open the service directly.
Verify organizations and login
Log in with the original administrator account and confirm the default organization, members, and project ownership. New instances enter the organization name during initialization; upgraded instances can change the migration-generated name in organization settings.
Check that each project has exactly one owner, public/private categories are correct, and default permissions and explicit roles match expectations. Spot-check API Keys, historical conversations, analysis canvases, and Workbooks. Have an imported enterprise member verify the full login URL and organization membership, then verify email delivery and business queries.
Organization members, roles, and enterprise integrations are managed in the Organization group of personal settings. System administrators retain the global user and project directories; the private deployment project directory does not automatically grant access to project content.
Additional Cloud release requirements: not routine private deployment operations
Cloud establishes organization membership according to original users and project owners, rather than merging the entire site into one default organization. Migration of organization subscriptions, balances, orders, and redemption records requires preflight checks and reconciliation on a production snapshot copy before execution during a window with Web/Worker writes paused.
If preflight reports cloud_legacy_enterprise_credentials or cloud_legacy_enterprise_config, stop the upgrade, export the affected data, and have the migration owner determine its ownership; migration does not guess the target organization. Empty historical WeCom/WPS configuration placeholder keys do not cause this block.
Domestic Cloud production also requires complete WeChat and SMS environment variables; see Deployment authentication configuration.
v4.1.x → v4.2.x (Qdrant → pgvector)
In this range, field vectors move from a separate Qdrant service to the pgvector extension in the main database. Upgrading from v4.1.x to v4.2.x requires:
Switch to a pgvector image
The official postgres image does not include the pgvector extension. Switch to an image that includes it (the migration script installs the extension automatically):
asktable-pg:
image: registry.cn-shanghai.aliyuncs.com/dminfra/pgvector:pg17 # Previously postgres:17Remove Qdrant
Compare against the latest Compose file in Private deployment (Docker). Remove the asktable_vdb service, the VDB_ADDRESS and VDB_API_KEY environment variables, and the qdrant_storage and qdrant_snapshots volumes.
Start the services
docker compose pull
docker compose down
docker compose up -dStartup automatically runs migration and installs the pgvector extension. If logs say the asktable_workbook database does not exist, create it as described in Private deployment (Docker).
Rebuild embeddings
Field vectors in old data sources are empty. Open each data source page and select “Settings” in the top bar → “Index maintenance” → “Rebuild Embedding”. A message indicates that rebuilding has started; semantic retrieval takes effect automatically when it finishes.
Collation version warning
This occurs only when the PostgreSQL image changes and the underlying glibc version changes with it. The identifying condition is collation version mismatch in docker compose logs asktable-pg or docker compose logs asktable.
- Installing pgvector in the existing PostgreSQL instance without changing its image → does not trigger it; skip this section.
- Replacing the old image (the
postgresimage used in early deployments) with a pgvector image while reusing the oldpostgres_datavolume → triggers it; follow the steps below.
Do not just refresh the version number as suggested by the message. Different glibc versions change text collation rules, so old text indexes no longer match the new rules, and queries can silently miss rows. Rebuild indexes first, then refresh the version number.
docker compose exec asktable-pg psql -U asktable -d asktable -c "REINDEX DATABASE asktable;"
docker compose exec asktable-pg psql -U asktable -d asktable -c "ALTER DATABASE asktable REFRESH COLLATION VERSION;"
docker compose exec asktable-pg psql -U asktable -d postgres -c "ALTER DATABASE template1 REFRESH COLLATION VERSION;"If Workbook is enabled, perform the same two steps on asktable_workbook. Do not empty a production data directory merely to remove the warning. This page's Compose file uses host bind directories, which down -v does not delete either.
Restore the version before the upgrade
Stop application writes before restoring. Use the pre-upgrade main database, Workbook database, business files, deployment configuration, and corresponding image as one restore point. Verify it in an isolated copy before restoring service. If the database has incompatible changes or migration removed data, switching back to an old image alone is insufficient to roll back.
Key constraints
| Item | Value or default | Where to change it |
|---|---|---|
| Upgrade method | Recreate containers after changing images; database schema migration runs automatically at startup | docker compose pull → down → up -d |
| Image tag | :latest; releases push both {version} and latest tags | image in docker-compose.yaml; pin a version number to support rollback |
| Main database image | registry.cn-shanghai.aliyuncs.com/dminfra/pgvector:pg17 | asktable-pg.image |
| Backup tool | pg_dump is available in the container (the image includes the PostgreSQL client) | docker compose exec asktable-pg pg_dump ... |
| Rollback | First check database compatibility; if incompatible or migration removed data, restore pre-upgrade databases, business files, and the corresponding old image and configuration | Use verified pre-upgrade backups |
| Data directories | The example uses host bind directories ./postgres_data, ./asktable_data, and ./redis_data; down -v does not delete them | volumes in docker-compose.yaml |
| Collation warning | Occurs only when changing the image while reusing old data volumes | REINDEX first, then REFRESH COLLATION VERSION |
| Field vectors | Stored in main database pgvector from v4.2.x; no longer uses separate Qdrant | Data source → “Settings” → “Index maintenance” → “Rebuild Embedding” |
Troubleshooting
| Symptom | How to identify it | Action |
|---|---|---|
| Version number unchanged after upgrade | System version under “About” is still old, and the asktable image ID in docker compose images has not changed | pull did not retrieve the new image; check outbound access and image tags |
| Container will not start | docker compose logs asktable shows errors related to the vector extension | asktable-pg still uses an image without pgvector; switch to a pgvector image and recreate it |
| Queries start missing rows | collation version mismatch appeared in logs | Follow “Collation version warning”: REINDEX first, then refresh the version number |
| Workbook errors | docker compose logs asktable shows workbook PG ping failed | Create the asktable_workbook database; see Private deployment (Docker) |
| Semantic retrieval worsens after upgrade | “Rebuild Embedding” has not been run in the data source's “Settings” → “Index maintenance” | Run one rebuild for each data source |
| Want to return to the old version | Backups were made as described in “Prerequisites” | Change the image tag back to the old version and recreate it; restore from backups if the data structure is incompatible |
| Database is running but the service cannot connect | Logs show a database authentication failure | Confirm DATABASE_PASSWORD matches POSTGRES_PASSWORD; differing values cause failures after recreation |
Next steps
- Private deployment (Docker) — Access URLs, upgrade commands, and troubleshooting
- Deploy AI Search (value indexing) — Value indexing and embeddings are separate
- Data source maintenance — Rebuild indexes and refresh metadata
- Deployment overview — Optional components and rollout order