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/requirements.mdx b/docs/self-hosting/configuration/requirements.mdx index e0e992b7f..7ed2691f2 100644 --- a/docs/self-hosting/configuration/requirements.mdx +++ b/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 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..60c6edbff --- /dev/null +++ b/docs/self-hosting/guides/upgrading-infisical.mdx @@ -0,0 +1,57 @@ +--- + +title: "Upgrade 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. 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. - diff --git a/frontend/src/components/secret-syncs/SecretSyncSelect.tsx b/frontend/src/components/secret-syncs/SecretSyncSelect.tsx index 6e3030a01..cbcba4513 100644 --- a/frontend/src/components/secret-syncs/SecretSyncSelect.tsx +++ b/frontend/src/components/secret-syncs/SecretSyncSelect.tsx @@ -10,9 +10,9 @@ type Props = { }; export const SecretSyncSelect = ({ onSelect }: Props) => { - const { isLoading, data: secretSyncOptions } = useSecretSyncOptions(); + const { isPending, data: secretSyncOptions } = useSecretSyncOptions(); - if (isLoading) { + if (isPending) { return (
diff --git a/frontend/src/components/secret-syncs/forms/SecretSyncConnectionField.tsx b/frontend/src/components/secret-syncs/forms/SecretSyncConnectionField.tsx index 60a81605b..94e587709 100644 --- a/frontend/src/components/secret-syncs/forms/SecretSyncConnectionField.tsx +++ b/frontend/src/components/secret-syncs/forms/SecretSyncConnectionField.tsx @@ -23,7 +23,7 @@ export const SecretSyncConnectionField = ({ onChange: callback }: Props) => { const destination = watch("destination"); const app = SECRET_SYNC_CONNECTION_MAP[destination]; - const { data: availableConnections, isLoading } = useListAvailableAppConnections(app); + const { data: availableConnections, isPending } = useListAvailableAppConnections(app); const connectionName = APP_CONNECTION_MAP[app].name; @@ -54,7 +54,7 @@ export const SecretSyncConnectionField = ({ onChange: callback }: Props) => { onChange(newValue); if (callback) callback(); }} - isLoading={isLoading} + isLoading={isPending} options={availableConnections} placeholder="Select connection..." getOptionLabel={(option) => option.name} diff --git a/frontend/src/layouts/OrganizationLayout/components/MinimizedOrgSidebar/MinimizedOrgSidebar.tsx b/frontend/src/layouts/OrganizationLayout/components/MinimizedOrgSidebar/MinimizedOrgSidebar.tsx index 01dcf4f0c..273c4f15b 100644 --- a/frontend/src/layouts/OrganizationLayout/components/MinimizedOrgSidebar/MinimizedOrgSidebar.tsx +++ b/frontend/src/layouts/OrganizationLayout/components/MinimizedOrgSidebar/MinimizedOrgSidebar.tsx @@ -323,12 +323,12 @@ export const MinimizedOrgSidebar = () => { Organization Options - }> + }> Access Control - }> + }> App Connections @@ -336,18 +336,20 @@ export const MinimizedOrgSidebar = () => { window.location.origin.includes("https://eu.infisical.com") || window.location.origin.includes("https://gamma.infisical.com")) && ( - }> + } + > Usage & Billing )} - }> + }> Audit Logs - }> + }> Organization Settings diff --git a/frontend/src/pages/organization/AppConnections/AppConnectionsPage/components/AppConnectionList.tsx b/frontend/src/pages/organization/AppConnections/AppConnectionsPage/components/AppConnectionList.tsx index 5db13f714..e6abba757 100644 --- a/frontend/src/pages/organization/AppConnections/AppConnectionsPage/components/AppConnectionList.tsx +++ b/frontend/src/pages/organization/AppConnections/AppConnectionsPage/components/AppConnectionList.tsx @@ -11,9 +11,9 @@ type Props = { }; export const AppConnectionsSelect = ({ onSelect }: Props) => { - const { isLoading, data: appConnectionOptions } = useAppConnectionOptions(); + const { isPending, data: appConnectionOptions } = useAppConnectionOptions(); - if (isLoading) { + if (isPending) { return (
diff --git a/frontend/src/pages/organization/AppConnections/AppConnectionsPage/components/AppConnectionsTable.tsx b/frontend/src/pages/organization/AppConnections/AppConnectionsPage/components/AppConnectionsTable.tsx index ee71669ba..379ce877c 100644 --- a/frontend/src/pages/organization/AppConnections/AppConnectionsPage/components/AppConnectionsTable.tsx +++ b/frontend/src/pages/organization/AppConnections/AppConnectionsPage/components/AppConnectionsTable.tsx @@ -51,7 +51,7 @@ type AppConnectionFilters = { }; export const AppConnectionsTable = () => { - const { isLoading, data: appConnections = [] } = useListAppConnections(); + const { isPending, data: appConnections = [] } = useListAppConnections(); const { popUp, handlePopUpOpen, handlePopUpToggle } = usePopUp([ "deleteConnection", @@ -262,7 +262,7 @@ export const AppConnectionsTable = () => { - {isLoading && ( + {isPending && ( )} {filteredAppConnections.slice(offset, perPage * page).map((connection) => ( @@ -285,7 +285,7 @@ export const AppConnectionsTable = () => { onChangePerPage={setPerPage} /> )} - {!isLoading && !filteredAppConnections?.length && ( + {!isPending && !filteredAppConnections?.length && (