Deleting migrations in remote deploy

[kausik10]

Hi
, is there a way to sync remote migrations with local migration in contember?

I have 2 deploys and one deploy consists of wrong migrations.
Locally, I deleted those migrations and executed some other migrations and pushed to one of the deploys.

The other deploy consists of locally deleted migrations. I don't need these migrations in remote as well.
So, I was looking for something to delete these migrations from remote so that I can sync with the latest correct migrations.
Thank you!

[jonasnobile]

Hi,

If you want to sync your local migrations with those already executed on a remote deploy, you can use the migrations:status command with the --restore-missing flag. This will reconstruct missing local migration files based on the remote migration history.

Example

CONTEMBER_API_URL="https://your-project-group-name.eu.contember.cloud" \
CONTEMBER_API_TOKEN="your-api-token" \
CONTEMBER_PROJECT_NAME="your-project-name" \
yarn contember migrations:status --restore-missing

Replace:

• your-project-group-name with your actual Contember project group name
• your-api-token with a valid API token
• your-project-name with your Contember project name

What it does

This command checks which migrations have been executed on the remote project and restores any that are missing locally. It’s especially useful if you’ve accidentally deleted migration files and don’t have them available in your local project anymore.

Important

This command does not delete or modify migrations on the remote project. If a migration has already been executed remotely, there's currently no supported way to remove it, in order to maintain consistency and prevent accidental schema issues.

If one of your remote deploys (e.g. staging or dev) contains outdated or incorrect migrations, and another deploy (like production) has the correct ones, it’s usually best to:

1. Delete the broken project.
2. Create a fresh one using the correct local migrations.
3. (Optional) Use the Data Transfer CLI to clone content from your good source (production/local) into the new project.

Let me know if you need help with any of the steps!

[kausik10]

Hi, Thank you for the detailed response. I ran into the issue of missing local migrations some months back and I am familiar with the solution to restore missing migrations locally. However, as you mention that contember doesn't allow us to delete the remote migrations as it might cause inconsistencies, I shall delete the current `stage` and create a new one. I don't want to change the `URL` , so I want to know how long it takes for the current `URL` to be available so that it will be easier to access on the same URL Also, the content api does not transfer the `tenant` data when transferring the data. Could you please let me know if I could transfer the `tenant` data as well? Thank you!

…

On Tue, 8 Apr 2025, 3:07 pm jonasnobile, ***@***.***> wrote: Hi, If you want to sync your local migrations with those already executed on a remote deploy, you can use the migrations:status command with the --restore-missing flag. This will *reconstruct missing local migration files* based on the remote migration history. Example CONTEMBER_API_URL="https://your-project-group-name.eu.contember.cloud" \ CONTEMBER_API_TOKEN="your-api-token" \ CONTEMBER_PROJECT_NAME="your-project-name" \ yarn contember migrations:status --restore-missing Replace: - your-project-group-name with your actual Contember project group name - your-api-token with a valid API token - your-project-name with your Contember project name What it does This command checks which migrations have been executed on the remote project and restores any that are missing *locally*. It’s especially useful if you’ve accidentally deleted migration files and don’t have them available in your local project anymore. Important This command *does not delete* or modify migrations on the remote project. If a migration has already been executed remotely, there's currently *no supported way to remove it*, in order to maintain consistency and prevent accidental schema issues. If one of your remote deploys (e.g. staging or dev) contains outdated or incorrect migrations, and another deploy (like production) has the correct ones, it’s usually best to: 1. Delete the broken project. 2. Create a fresh one using the correct local migrations. 3. (Optional) Use the Data Transfer CLI <https://docs.contember.com/reference/engine/content/transfer/#data-transfer> to clone content from your good source (production/local) into the new project. Let me know if you need help with any of the steps! — Reply to this email directly, view it on GitHub <#758 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXHQMXEGY45XNHERVK7EASD2YOIL5AVCNFSM6AAAAAB2UCAVAGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENZWGE4TCOI> . You are receiving this because you authored the thread.Message ID: ***@***.*** .com>

[jonasnobile]

If you have different migrations in production and stage, the only way to fix this right now is to create a new stage project.

Due to security concerns, we do not release project URLs that have already been used. This is by design—to prevent someone else from re-creating a project under the same URL and potentially gaining access to client integrations or assumptions tied to that name. This means you won’t be able to reuse the same URL after deleting a project.

We also don’t transfer tenant data (users, roles, API tokens, etc.) for the same reason—security. The tenant is shared across multiple projects and can contain data that’s specific to a different project than the one you're trying to transfer.

[kausik10]

Thank you for the detailed response. This clears a lot of my confusions. I, however, have a concern. If I use `--include-system: This option includes system schema (with event log) in the export.` with `data:export` it says it contains all the logs. However, when I import to another project (remote or local), it won't contain tenant db's data as you mentioned. Let's say I have a `prod` with `users` seemingly connected to a `person` table which references `tenantPerson` that consists of all the roles, email for the `user` (Standard setup from contember's AI studio). Then, do I not have an option to extract these fields with `data:export` at all?

…

On Wed, Apr 9, 2025 at 1:39 PM jonasnobile ***@***.***> wrote: If you have different migrations in production and stage, the only way to fix this right now is to create a new stage project. Due to security concerns, we do not release project URLs that have already been used. This is by design—to prevent someone else from re-creating a project under the same URL and potentially gaining access to client integrations or assumptions tied to that name. This means you won’t be able to reuse the same URL after deleting a project. We also don’t transfer tenant data (users, roles, API tokens, etc.) for the same reason—security. The tenant is shared across multiple projects and can contain data that’s specific to a different project than the one you're trying to transfer. — Reply to this email directly, view it on GitHub <#758 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXHQMXFNV6SPO5UF5S52ZPD2YTG4FAVCNFSM6AAAAAB2UCAVAGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENZXGQ3TEMA> . You are receiving this because you authored the thread.Message ID: ***@***.*** .com>

[jonasnobile]

You're absolutely right to ask, and I appreciate you highlighting this—it’s a common point of confusion, so let me clarify a few things.

The --include-system flag in data:export does not include the tenant database. It only includes the system database, which is used internally by Contember to store event logs and other infrastructure-level data. This is distinct from the tenant database, which contains users, roles, API tokens, and other access-related data. So, even if you export with --include-system, the tenant data will not be part of that export.

Let's say I have a prod with users seemingly connected to a person
table which references tenantPerson that consists of all the roles, email
for the user (Standard setup from contember's AI studio).
Then, do I not have an option to extract these fields with data:export at
all?

Correct. In the AI Studio setup, the TenantPerson is typically just a SQL view that joins your content schema (e.g., Person) with the tenant schema (e.g., Person, Identity, etc.). When you export the content database, you’re only exporting one side of that relationship—the tenant side is excluded for security and architectural reasons.

If you need to recreate your tenant data (e.g., users), you can do so manually or programmatically. Here's the general approach:

1. Export the necessary user-related data from your current environment (e.g., emails and roles) via custom scripts.
2. Recreate the users in the new tenant database using the Tenant API.
3. Update the personId references in your content schema to match the new tenant identities, ensuring the link between Person and User is restored.

We're aware this process isn't ideal for every use case, and improving how tenant data can be backed up or migrated is something we’re actively exploring. If you have a more specific migration scenario in mind, I’d be happy to offer suggestions tailored to that!

Let me know how I can help further.

[kausik10]

Sure, thank you very much. I will reach out to you if I run into such circumstances!