update hardware for infisical

Improvement: Use isPending Over isLoading

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.
 

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"
           ]

docs/self-hosting/configuration/requirements.mdx

@@ -22,33 +22,34 @@ The actual resource requirements will vary in direct proportion to the operation
 Infisical doesn’t require file storage as all persisted data is saved in the database. 
 However, its logs and metrics are saved to disk for later viewing. As a result, we recommend provisioning 1-2 GB of storage.
 
-### CPU
+### CPU and Memory (Per Container/Instance)
 
-CPU requirements vary heavily on the volume of secret operations (reads and writes) you anticipate. 
-Processing large volumes of secrets frequently and consistently will require higher CPU.
+Infisical is stateless and scales horizontally by running across multiple containers/instances. Each instance typically does **not** need more than **2–4 CPU cores** and **4–8 GB** of memory. 
+If you need additional capacity, simply increase the **number** of containers/instances running in parallel.
 
-Recommended minimum CPU hardware for different sizes of deployments:
+| **Deployment Size** | **CPU (Cores, per container)** | **Memory (GB, per container)** | **Recommended Number of Containers** |
+|---------------------|--------------------------------|--------------------------------|--------------------------------------|
+| **Small**           | 2                              | 4                              | 2+                                   |
+| **Medium**          | 2–4                            | 4–8                            | 5+                                   |
+| **Large**           | 2–4                            | 4–8                            | 10+                                  |
 
-- **small:** 2-4 core is the **recommended** minimum
-- **large:** 4-8 cores are suitable for larger deployments
-
-### Memory Allocation
-
-Memory needs depend on expected workload, including factors like user activity, automation level, and the frequency of secret operations.
-
-Recommended minimum memory hardware for different sizes of deployments:
-- **small:** 4-8 GB is the **recommended** minimum
-- **large:** 16-32 GB are suitable for larger deployments
+> **Note:**  
+> - Adding more containers (horizontal scaling) is generally the best way to handle spikes in secret operations.  
+> - If you prefer, you can increase CPU/memory on a single container (vertical scaling), but horizontal scaling is more flexible and resilient.
 
 ## Database & caching layer
 
 ### Postgres
 
 PostgreSQL is the only database supported by Infisical. Infisical has been extensively tested with Postgres version 16. We recommend using versions 14 and up for optimal compatibility.
+The compute required for Postgres is largely dependent on the number of secret operations (reads and writes) you expect. The more frequently you read and write secrets, the more compute you will need.
+You'll notice that storage requirements are high and this is because audit logs are by default stored in the database.
 
-Recommended resource allocation based on deployment size:
-- **small:** 2 vCPU / 8 GB RAM / 20 GB Disk
-- **large:** 4vCPU / 16 GB RAM / 100 GB Disk
+
+Recommended resource allocation based on deployment size. You may require more resources if you have a large number of secrets or high transaction volume:
+- **small:** 2 vCPU / 8 GB RAM / 100 GB Disk
+- **medium:** 4vCPU / 16 GB RAM / 200 GB Disk
+- **large:** 8vCPU / 32 GB RAM / 500 GB Disk
 
 ### Redis
 

docs/self-hosting/configuration/schema-migrations.mdx

@@ -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
-
-<Steps>
-  <Step title="Pull the Infisical Docker Image">
-    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:<version>
-    ```
-    Replace `<version>` with the specific version number you intend to deploy. View available versions [here](https://hub.docker.com/r/infisical/infisical/tags)
-  </Step>
-
-  <Step title="Set Up the Environment Variable">
-    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`.
-  </Step>
-
-  <Step title="Run the Migration ">
-    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=<your_connection_string> infisical/infisical:<version> npm run migration:latest
-    ```
-    Replace `<your_connection_string>` with your actual PostgreSQL connection string, and `<version>` with the desired version number.
-  </Step>
-
-  <Step title="Verify the Migration">
-    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.
-  </Step>
-  <Step title="Rollback If Needed">
-    If you need to rollback a migration by one step, use the following command:
-
-    ```bash
-    docker run --env DB_CONNECTION_URI=<your_connection_string> infisical/infisical:<version> npm run migration:rollback
-    ```
-  </Step>
-
-  <Step title="Repeat for Each Version">
-    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.
-  </Step>
-</Steps>
-
-<Tip>
-  In a production setting, we recommend a more structured approach to deploying migrations prior to upgrading Infisical. This can be accomplished via CI automation.
-</Tip>
-
-### 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.

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
     ```
-
-    <Note>
-      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.
-    </Note>
-  </Step>
-
-  <Step title="Run schema migrations">
-    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. 
-
-    <Info>
-      After running the schema migrations, be sure to update the `.env` file to have the correct `DB_CONNECTION_URI`.
-    </Info> 
   </Step>
 
   <Step title="View service status">

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
     </Tabs>
   </Step>
 
-  <Step title="Database schema migration ">
-    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.
-
-    <Info>
-      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.
-    </Info>
-  </Step>
-
   <Step title="Routing traffic to Infisical">
     By default, this chart uses Nginx as its Ingress controller to direct traffic to Infisical services.
 

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 `<version>` with the docker image tag of your choice.
   </Step>
-  <Step title="Run Postgres schema migration ">
-    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.
-    
-  </Step>
   <Step title="Start 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).
     

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. 

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
 <Accordion title="Can Infisical run in an air-gapped environment without any internet access?" defaultOpen >
     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.
 </Accordion>
-<Accordion title="Since RDS is in a private subnet, how do run the Postgres schema migrations?">
-    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.
-</Accordion>

frontend/src/layouts/OrganizationLayout/components/MinimizedOrgSidebar/MinimizedOrgSidebar.tsx

@@ -323,12 +323,12 @@ export const MinimizedOrgSidebar = () => {
                 <DropdownMenuContent align="start" side="right" className="p-1">
                   <DropdownMenuLabel>Organization Options</DropdownMenuLabel>
                   <Link to="/organization/access-management">
-                    <DropdownMenuItem icon={<FontAwesomeIcon icon={faUsers} />}>
+                    <DropdownMenuItem icon={<FontAwesomeIcon className="w-3" icon={faUsers} />}>
                       Access Control
                     </DropdownMenuItem>
                   </Link>
                   <Link to="/organization/app-connections">
-                    <DropdownMenuItem icon={<FontAwesomeIcon icon={faPlug} />}>
+                    <DropdownMenuItem icon={<FontAwesomeIcon className="w-3" icon={faPlug} />}>
                       App Connections
                     </DropdownMenuItem>
                   </Link>
@@ -336,18 +336,20 @@ export const MinimizedOrgSidebar = () => {
                     window.location.origin.includes("https://eu.infisical.com") ||
                     window.location.origin.includes("https://gamma.infisical.com")) && (
                     <Link to="/organization/billing">
-                      <DropdownMenuItem icon={<FontAwesomeIcon icon={faMoneyBill} />}>
+                      <DropdownMenuItem
+                        icon={<FontAwesomeIcon className="w-3" icon={faMoneyBill} />}
+                      >
                         Usage & Billing
                       </DropdownMenuItem>
                     </Link>
                   )}
                   <Link to="/organization/audit-logs">
-                    <DropdownMenuItem icon={<FontAwesomeIcon icon={faBook} />}>
+                    <DropdownMenuItem icon={<FontAwesomeIcon className="w-3" icon={faBook} />}>
                       Audit Logs
                     </DropdownMenuItem>
                   </Link>
                   <Link to="/organization/settings">
-                    <DropdownMenuItem icon={<FontAwesomeIcon icon={faCog} />}>
+                    <DropdownMenuItem icon={<FontAwesomeIcon className="w-3" icon={faCog} />}>
                       Organization Settings
                     </DropdownMenuItem>
                   </Link>