diff --git a/docs/contributing/platform/backend/how-to-create-a-feature.mdx b/docs/contributing/platform/backend/how-to-create-a-feature.mdx
index 8449eb501..f02040cfa 100644
--- a/docs/contributing/platform/backend/how-to-create-a-feature.mdx
+++ b/docs/contributing/platform/backend/how-to-create-a-feature.mdx
@@ -4,9 +4,6 @@ title: "Backend development guide"
Suppose you're interested in implementing a new feature in Infisical's backend, let's call it "feature-x." Here are the general steps you should follow.
-## Database schema migration
-In order to run [schema migrations](https://en.wikipedia.org/wiki/Schema_migration#:~:text=A%20schema%20migration%20is%20performed,some%20newer%20or%20older%20version) you need to expose your database connection string. Create a `.env.migration` file to set the database connection URI for migration scripts, or alternatively, export the `DB_CONNECTION_URI` environment variable.
-
## Creating new database model
If your feature involves a change in the database, you need to first address this by generating the necessary database schemas.
diff --git a/docs/mint.json b/docs/mint.json
index babb9be1a..b62af6533 100644
--- a/docs/mint.json
+++ b/docs/mint.json
@@ -285,7 +285,7 @@
"pages": [
"self-hosting/overview",
{
- "group": "Containerized installation methods",
+ "group": "Installation methods",
"pages": [
"self-hosting/deployment-options/standalone-infisical",
"self-hosting/deployment-options/docker-swarm",
@@ -293,12 +293,12 @@
"self-hosting/deployment-options/kubernetes-helm"
]
},
+ "self-hosting/guides/upgrading-infisical",
"self-hosting/configuration/envars",
"self-hosting/configuration/requirements",
{
"group": "Guides",
"pages": [
- "self-hosting/configuration/schema-migrations",
"self-hosting/guides/mongo-to-postgres",
"self-hosting/guides/custom-certificates"
]
diff --git a/docs/self-hosting/configuration/schema-migrations.mdx b/docs/self-hosting/configuration/schema-migrations.mdx
deleted file mode 100644
index 5df52e713..000000000
--- a/docs/self-hosting/configuration/schema-migrations.mdx
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: "Schema migration"
-description: "Learn how to run Postgres schema migrations."
----
-
-Running schema migrations is a requirement before deploying Infisical.
-Each time you decide to upgrade your version of Infisical, it's necessary to run schema migrations for that specific version.
-The guide below outlines a step-by-step guide to help you manually run schema migrations for Infisical.
-
-### Prerequisites
-- Docker installed on your machine
-- An active PostgreSQL database
-- Postgres database connection string
-
-
-
- First, ensure you have the correct version of the Infisical Docker image. You can pull it from Docker Hub using the following command:
- ```bash
- docker pull infisical/infisical:
- ```
- Replace `` with the specific version number you intend to deploy. View available versions [here](https://hub.docker.com/r/infisical/infisical/tags)
-
-
-
- The Docker image requires a `DB_CONNECTION_URI` environment variable. This connection string should point to your PostgreSQL database. The format generally looks like this: `postgresql://username:password@host:port/database`.
-
-
-
- To run the schema migration for the version of Infisical you want to deploy, use the following Docker command:
-
- ```bash
- docker run --env DB_CONNECTION_URI= infisical/infisical: npm run migration:latest
- ```
- Replace `` with your actual PostgreSQL connection string, and `` with the desired version number.
-
-
-
- After running the migration, it's good practice to check if the migration was successful. You can do this by checking the logs or accessing your database to ensure the schema has been updated accordingly.
-
-
- If you need to rollback a migration by one step, use the following command:
-
- ```bash
- docker run --env DB_CONNECTION_URI= infisical/infisical: npm run migration:rollback
- ```
-
-
-
- It's important to run schema migrations for each version of the Infisical you deploy. For instance, if you're updating from `infisical/infisical:1` to `infisical/infisical:2`, ensure you run the schema migrations for `infisical/infisical:2` before deploying it.
-
-
-
-
- In a production setting, we recommend a more structured approach to deploying migrations prior to upgrading Infisical. This can be accomplished via CI automation.
-
-
-### Additional discussion
-- Always back up your database before running migrations, especially in a production environment.
-- Test the migration process in a staging environment before applying it to production.
-- Keep track of the versions and their corresponding migrations to avoid any inconsistencies.
diff --git a/docs/self-hosting/deployment-options/docker-swarm.mdx b/docs/self-hosting/deployment-options/docker-swarm.mdx
index 5fce38b29..c7280d879 100644
--- a/docs/self-hosting/deployment-options/docker-swarm.mdx
+++ b/docs/self-hosting/deployment-options/docker-swarm.mdx
@@ -157,23 +157,6 @@ The [Docker stack file](https://github.com/Infisical/infisical/tree/main/docker-
3lznscvk7k5t infisical_spolo2 replicated 1/1 ghcr.io/zalando/spilo-16:3.2-p2
v04ml7rz2j5q infisical_spolo3 replicated 1/1 ghcr.io/zalando/spilo-16:3.2-p2
```
-
-
- You'll notice that service `infisical_infisical` will not be in running state.
- This is expected as the database does not yet have the desired schemas.
- Once the database schema migrations have been successfully applied, this issue should be resolved.
-
-
-
-
- Run the schema migration to initialize the database. Follow the [guide here](/self-hosting/configuration/schema-migrations) to learn how.
-
- To run the migrations, you'll need to connect to the Postgres instance deployed on your Docker swarm. The default Postgres user credentials are defined in the Docker swarm: username: `postgres`, password: `postgres` and database: `postgres`.
- We recommend you change these credentials when deploying to production and creating a separate DB for Infisical.
-
-
- After running the schema migrations, be sure to update the `.env` file to have the correct `DB_CONNECTION_URI`.
-
diff --git a/docs/self-hosting/deployment-options/kubernetes-helm.mdx b/docs/self-hosting/deployment-options/kubernetes-helm.mdx
index 35b003c2d..e0e5ba75d 100644
--- a/docs/self-hosting/deployment-options/kubernetes-helm.mdx
+++ b/docs/self-hosting/deployment-options/kubernetes-helm.mdx
@@ -78,18 +78,6 @@ description: "Learn how to use Helm chart to install Infisical on your Kubernete
-
- Infisical relies on a relational database, which means that database schemas need to be migrated before the instance can become operational.
-
- To automate this process, the chart includes a option named `infisical.autoDatabaseSchemaMigration`.
- When this option is enabled, a deployment/upgrade will only occur _after_ a successful schema migration.
-
-
- If you are using in-cluster Postgres, you may notice the migration job failing initially.
- This is expected as it is waiting for the database to be in ready state.
-
-
-
By default, this chart uses Nginx as its Ingress controller to direct traffic to Infisical services.
diff --git a/docs/self-hosting/deployment-options/standalone-infisical.mdx b/docs/self-hosting/deployment-options/standalone-infisical.mdx
index 6e41e4b5f..b7f76ce98 100644
--- a/docs/self-hosting/deployment-options/standalone-infisical.mdx
+++ b/docs/self-hosting/deployment-options/standalone-infisical.mdx
@@ -22,11 +22,6 @@ The following guide provides a detailed step-by-step walkthrough on how you can
Remember to replace `` with the docker image tag of your choice.
-
- Before you can start the instance of Infisical, you need to run the database schema migrations.
- Follow the step by [step guide here](/self-hosting/configuration/schema-migrations) on running schema migrations for Infisical.
-
-
For a minimal installation of Infisical, you must configure `ENCRYPTION_KEY`, `AUTH_SECRET`, `DB_CONNECTION_URI`, `SITE_URL`, and `REDIS_URL`. [View all available configurations](/self-hosting/configuration/envars).
diff --git a/docs/self-hosting/guides/upgrading-infisical.mdx b/docs/self-hosting/guides/upgrading-infisical.mdx
new file mode 100644
index 000000000..809097bd9
--- /dev/null
+++ b/docs/self-hosting/guides/upgrading-infisical.mdx
@@ -0,0 +1,57 @@
+---
+
+title: "Upgrade Your Infisical Instance"
+description: "How to upgrade Infisical self-hosted instance"
+
+---
+
+Keeping your Infisical instance up to date is key to making sure you receive the latest performance improvements, security patches, and feature updates.
+We release updates approximately once a week, which may include new features, bug fixes, performance enhancements, and critical security patches.
+
+Since secrets management is a critical component of your infrastructure, we aim to avoid disruptive changes that will impact fetching secrets in downstream clients.
+If a release requires specific attention, a note will be attached to the corresponding [release](https://github.com/Infisical/infisical/releases) version.
+
+During an upgrade, two key components are updated:
+
+- **Infisical Application:** The core application code is updated.
+- **PostgreSQL Database Schema:** Schema migrations run automatically to ensure your database remains in sync with the updated application.
+
+> **Before You Upgrade:**
+> **Always back up your database.** While our automated migration system is robust, having a backup ensures you can recover quickly in the event of an issue.
+
+## Automated Schema Migrations
+
+In previous versions (prior to `v0.111.0-postgres`), schema migrations had to be executed manually before starting the application.
+Now, migrations run automatically during boot-up. This improvement streamlines the upgrade process, reduces manual steps, and minimizes the risk of inconsistencies between your database schema and application code.
+
+### Benefits of Automated Migrations
+
+- **Seamless Integration:**
+ Migrations are now part of the boot-up process, removing the need for manual intervention.
+
+- **Synchronous Upgrades:**
+ In multi-instance deployments, one instance acquires a lock and performs the migration while the others wait. This ensures that if a migration fails, the rollout is halted to prevent inconsistencies.
+
+- **Reduced Room for Error:**
+ Automatic migrations help ensure that your database schema always remains in sync with your application code.
+
+## Upgrade Steps
+
+1. **Back Up Your Data:**
+ - Ensure you have a complete backup of your Postgres database.
+ - Verify that your backup is current and accessible.
+
+2. **Select the Upgrade Version:**
+ - Visit the [Infisical releases page](https://github.com/Infisical/infisical/releases) for a list of available versions.
+ - Look for releases with the prefix `infisical/` as there are other releases that are not related to the Infisical instance.
+
+3. **Start the Upgrade Process:**
+ - Launch the new version of Infisical. During startup, the application will automatically compare the current database schema with the updated schema in the code.
+ - If any differences are detected, Infisical will apply the necessary migrations automatically.
+
+4. **Multi-Instance Coordination:**
+ - In environments with multiple instances, one instance will acquire a lock and perform the migration while the other instances wait.
+ - Once the migration is complete, all instances will operate with the updated schema.
+
+5. **Verify the Upgrade:**
+ - Review the logs for any migration errors or warnings.
\ No newline at end of file
diff --git a/docs/self-hosting/reference-architectures/aws-ecs.mdx b/docs/self-hosting/reference-architectures/aws-ecs.mdx
index 5a71c9572..12deaa3cb 100644
--- a/docs/self-hosting/reference-architectures/aws-ecs.mdx
+++ b/docs/self-hosting/reference-architectures/aws-ecs.mdx
@@ -48,9 +48,3 @@ This ensures that if there is a failure in one availability zone, the working re
Yes, Infisical can function in an air-gapped environment. To do so, update your ECS task to use the publicly available AWS Elastic Container Registry (ECR) image instead of the default Docker Hub image. Additionally, it's necessary to configure VPC endpoints, which allows your system to access AWS ECR via a private network route instead of the internet, ensuring all connectivity remains within the secure, private network.
-
- Since the Amazon RDS instance is housed within a private network to enhance security, it is not directly accessible from the internet. This means that in order to run the required [Postgres schema migrations](/self-hosting/configuration/schema-migrations), you need to connect to this instance of RDS. There are many approaches you can take:
- - To automate schema migrations, you may setup CI/CD pipeline with access to the same RDS network to run the schema migrations before making deployment to ECS. This ensures that if migrations fail, your Infisical instances continues to run.
- - If you would like to run the migrations manually, consider using AWS Systems Manager Session Manager to access the RDS within the VPC on your local machine.
- - If your organization already has mechanisms in place for secure access to the VPC, such as VPNs or Direct Connect, these can also be utilized for performing database migrations manually.
-