@@ -43,19 +43,9 @@ export default defineDmnoService({
 :::tip[Plugin instance IDs]
 You must give each plugin instance a unique id so we can refer to it in other services and the [`dmno` CLI](/docs/reference/cli/plugin/).
 
-In this case we used `1pass`, but you can imagine splitting vaults and access, and having multiple plugin instances - for example `1pass/prod` for highly sensitive production secrets and `1pass/dev` for everything else.
+See [Segmenting secrets](/docs/guides/segmenting-secrets/) for more details.
 :::
 
-### Injecting the plugin in monorepo services
-In a monorepo, you are likely managing secrets for multiple services. If you will be using the same service account(s) to access those secrets, you can initialize a plugin instance once in your root service as seen above, and then _inject_ it in child services. Note we must use that same id we set during initialization.
-
-```typescript title='apps/some-service/.dmno/config.mts'
-import { OnePasswordDmnoPlugin } from '@dmno/1password-plugin';
-
-// 💉 inject the already initialized plugin instead of re-initializing it
-const onePassSecrets = OnePasswordDmnoPlugin.injectInstance('1pass');
-```
-
 
 ------------
 
@@ -78,13 +68,7 @@ If you already use 1password and your secrets live in a vault that holds other i
 
 </Steps>
 
-This service account token will now serve as your "secret-zero" - which grants access to the rest of your sensitive config stored in 1Password. It must be set locally (unless relying on cli-based auth) and in deployed environments. It is sensitive so we must pass in the value as an _override_ rather than storing it within the config. Locally this usually means storing it in your [`.env.local` file](/docs/guides/env-files/) and on a deployed environment you'll usually set it within some kind of UI, wherever you would normally pass in environment variables.
-
-```diff title=".dmno/.env.local"
-+OP_TOKEN=ops_abc123...
-```
-
-Note that the config path of `OP_TOKEN` is arbitrary and you can see how it was wired up from your config schema to the plugin input in the example above. If you are using multiple vaults and service accounts, you may have something more like `OP_TOKEN_PROD` and `OP_TOKEN_DEV`.
+This service account token will now serve as your _secret-zero_ - which grants access to the rest of your sensitive config stored in 1Password. It must be set locally (unless relying on cli-based auth) and in any deployed environments. It is sensitive so we must pass in the value as an _override_ rather than storing it within the config. See [Setting overrides](/docs/guides/env-files/#setting-overrides-via-env-files) for more details.
 
 :::tip[Vault organization best practices]
 Consider how you want to organize your vaults and service accounts, keeping in mind [best practices](https://support.1password.com/business-security-practices/#access-management-and-the-principle-of-least-privilege). At a minimum, DMNO recommends having a vault for highly sensitive production secrets and another for everything else.
@@ -242,16 +226,9 @@ Field IDs are not easy to get from the 1Password UI. Luckily when the supplied f
 The secret reference for invidivual fields within an item can be found by clicking on the down arrow icon **on the field** and selecting `Copy Secret Reference`.
 :::
 
-## Caching
-In order to avoid rate limits and keep dev server restarts extremely fast, we heavily cache data fetched from external sources. After updating secrets in 1password, if the item has been cached, you'll need to clear the cache to see it take effect.
-
-- Use the [`dmno clear-cache` command](/docs/reference/cli/clear-cache/) to clear the cache once
-- The [`dmno resolve`](/docs/reference/cli/resolve/) and [`dmno run`](/docs/reference/cli/run/) commands have cache related flags:
-  - `--skip-cache` - skips caching logic altogether
-  - `--clear-cache` - clears the cache once before continuing as normal
 
 :::tip[Active config iteration]
 While you are actively working on the config itself, `dmno resolve -w --skip-cache` will combine watch mode with skipping cache logic.
 
-Once you are satisfied, _clear_ the cache once more and you are good to go.
+See [caching](/docs/plugins/overview/#caching) for more details.
 :::
@@ -46,16 +46,6 @@ You must give each plugin instance a unique id so we can refer to it in other se
 In this case we used `bitwarden`, but you can imagine splitting vaults and access, and having multiple plugin instances - for example `bitwarden/prod` for highly sensitive production secrets and `bitwarden/dev` for everything else.
 :::
 
-### Injecting the plugin in monorepo services
-In a monorepo, you are likely managing secrets for multiple services. If you will be using the same service account(s) to access those secrets, you can initialize a plugin instance once in your root service as seen above, and then inject it in child services. Note we must use that same id we set during initialization.
-
-```typescript title='apps/some-service/.dmno/config.mts'
-import { BitwardenSecretsManagerDmnoPlugin } from '@dmno/bitwarden-plugin';
-
-// 💉 inject the already initialized plugin instead of re-initializing it
-const bitwardenPlugin = BitwardenSecretsManagerDmnoPlugin.injectInstance('bitwarden');
-```
-
 
 ------------
 
@@ -64,34 +54,12 @@ const bitwardenPlugin = BitwardenSecretsManagerDmnoPlugin.injectInstance('bitwar
 If you are already using Bitwarden Secrets Manager, you likely already have existing [projects](https://bitwarden.com/help/projects/) that contain [secrets](https://bitwarden.com/help/secrets/). If so, now would be a good time to review how they are all organized. If not, you should create at least one project, as each secret can have a parent project it belongs to, and access can be granted to projects rather than managing each secret individually.
 
 :::tip[Use projects to segment access]
-You should use multiple projects to segment your secrets following the [Principle of Least Privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege). This means at minimum, you should have one project for ultra-sensitive production secrets, and another for everything else. How much more you want to break things up is up to you and will depend on your security requirements.
-
-It is technically possible to create secrets without using projects and/or to assign permissions at the individual secret level, but we do not recommend it.
+You should use multiple projects to segment your secrets following the [Principle of Least Privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege). See more in our [Secret segmentation](/docs/guides/secret-segmentation/) guide.
 :::
 
-## Setup Machine Account & Access Tokens
-
-Machine accounts can be granted access to projects, and each machine account can have multiple access tokens with optional expiration. How you want to manage this is up to you, but a sensible approach could be:
 
-- Production machine account has access to all projects
-  - single access token is used at a time
-- Staging/CI machine account has access to all projects except ultra-sensitive prod secrets
-  - each environment/CI/external tool could have a unique access token
-- Dev machine account has access to secrets needed for local dev
-  - each developer could have a unique access token
-
-Expiring tokens are more secure, but require the overhead of rolling those tokens, which must be done manually. Not wanting to cause an outage, you may want to roll them manually without the pressure of a potentially forgotten expiry date. To roll without downtime, create a new token, redeploy, and then decommission the previous token.
-
-### 
-
-
-Machine account access tokens now serve as your _secret-zero_ - which grants access to the rest of your sensitive config stored in Bitwarden. It must be set locally and in deployed environments, but it is sensitive so we must pass in the value as an _override_ rather than storing it within the config. Locally, this usually means storing it in your [`.env.local` file](/docs/guides/env-files/) and on a deployed environment you'll usually set it within some kind of UI, wherever you would normally pass in environment variables.
-
-```diff title=".dmno/.env.local"
-+BWS_TOKEN=0.abc123...
-```
+Machine account access tokens now serve as your _secret-zero_ - which grants access to the rest of your sensitive config stored in Bitwarden. It must be set locally and in deployed environments, but it is sensitive so we must pass in the value as an _override_ rather than storing it within the config. Locally, this usually means storing it in your [`.env.local` file](/docs/guides/env-files/) and on a deployed environment you'll usually set it wherever you would normally pass in environment variables. DMNO will handle the rest. See [Setting overrides](/docs/guides/env-files/#setting-overrides-via-env-files) for more details.
 
-Note that the config path of `BWS_TOKEN` is arbitrary and you can see how it was wired up from your config schema to the plugin input in the example above.
 
 ------
 
 
@@ -20,18 +20,18 @@ Install the package in the service(s) that will use secrets from Infisical.
 After installation, you'll need to initialize the plugin in your `config.mts` and add a few config items that are necessary to authenticate with Infisical and fetch secrets. It's ok if you have not created the machine identity or client keys - we'll do that in the next section.
 
 ```diff lang="ts" title='.dmno/config.mts'
-import { InfisicalSecretsManagerDmnoPlugin, InfisicalSecretsManagerTypes } from '@dmno/infisical-plugin';
+import { InfisicalDmnoPlugin, InfisicalTypes } from '@dmno/infisical-plugin';
 
 // explicitly wire the plugin instance to the config path
-const infisicalPlugin = new InfisicalSecretsManagerDmnoPlugin('infisical/dev', {
+const infisicalPlugin = new InfisicalDmnoPlugin('infisical/dev', {
   environment: 'development',
   clientId: configPath('..', 'INFISICAL_CLIENT_ID'),
   clientSecret: configPath('..', 'INFISICAL_CLIENT_SECRET'),
   projectId: configPath('..', 'INFISICAL_PROJECT_ID'),
 });
 
 // or you can inject by default
-const infisicalPlugin2 = new InfisicalSecretsManagerDmnoPlugin('infisical/prod', {
+const infisicalPlugin2 = new InfisicalDmnoPlugin('infisical/prod', {
   environment: 'production',
 }); 
 
@@ -58,7 +58,7 @@ See our [General plugin guidelines](/docs/plugins/overview/#general-plugin-guide
 
 ### Project & secrets
 
-If you are already using Infisical, you probably already have existing projects and secrets. If not, you should create at least one [project](https://infisical.com/docs/documentation/platform/project). Infisical uses the concept of [environments](https://infisical.com/docs/documentation/platform/project#project-environments) to group secrets. Make sure to make your secrets available in the same environment configuration as each plugin instance.
+If you are an existing Infisical user, you probably already have projects and secrets. If not, you should create at least one [project](https://infisical.com/docs/documentation/platform/project). Infisical uses the concept of [environments](https://infisical.com/docs/documentation/platform/project#project-environments) to group secrets. Make sure to make your secrets available in the same environment configuration as each plugin instance.
 
 ### Machine identity & client keys
 
@@ -75,22 +75,35 @@ Also note that the **Client Secret** is highly sensitive and should be treated a
 The Infisical plugin provides one method for fetching secrets, based on the name of the secret. The name itself will be inferred from the config item name. You can optionally pass a name if you wish to override the default.
 
 ```typescript title='.dmno/config.mts'
-import { InfisicalSecretsManagerDmnoPlugin, InfisicalSecretsManagerTypes } from '@dmno/infisical-plugin';
+import { InfisicalDmnoPlugin, InfisicalTypes } from '@dmno/infisical-plugin';
 
-const infisicalPlugin = new InfisicalSecretsManagerDmnoPlugin('infisical/dev', {
+const infisicalPlugin = new InfisicalDmnoPlugin('infisical/dev', {
   environment: 'development',
 });
 
 export default defineDmnoService({
   schema: {
     SOME_SECRET: {
       // this will fetch the secret with the name 'SOME_SECRET' from the project specified in the plugin instance
-      value: InfisicalPlugin.secret(),
+      value: infisicalPlugin.secret(),
     },
     SOME_NEW_SECRET: {
       // this will fetch the secret with the name 'SOME_OTHER_SECRET' and make it available as SOME_NEW_SECRET in your DMNO_CONFIG
-      value: InfisicalPlugin.secret('SOME_OTHER_SECRET'),
+      value: infisicalPlugin.secret('SOME_OTHER_SECRET'),
     },
   },
 });
 ```
+
+### Self-hosted Infisical
+
+If you are using a self-hosted version of Infisical, the `InfisicalDmnoPlugin` takes an optional `siteUrl` parameter. For example:
+
+```typescript title='.dmno/config.mts'
+import { InfisicalDmnoPlugin, InfisicalTypes } from '@dmno/infisical-plugin';
+
+const infisicalPlugin = new InfisicalDmnoPlugin('infisical/dev', {
+  environment: 'development',
+  siteUrl: 'https://infisical.mycompany.com',
+});
+```