diff --git a/website/docs/core-concepts/components/terraform/brownfield.mdx b/website/docs/core-concepts/components/terraform/brownfield.mdx
index 2a7a2b597..899f867ad 100644
--- a/website/docs/core-concepts/components/terraform/brownfield.mdx
+++ b/website/docs/core-concepts/components/terraform/brownfield.mdx
@@ -23,7 +23,7 @@ By understanding these challenges, teams can better prepare for a smooth transit
## Brownfield Development in Atmos
Atmos is easier for new organizations or "greenfield" environments because you need to architect Terraform according to
-our [best practices](/best-practices/components) to get all the benefits of Atmos. For example, when using our [Terraform components](https://github.com/cloudposse/terraform-aws-components), we frequently use [Terraform Remote State](/core-concepts/components/terraform/remote-state) to retrieve the outputs from other components.
+our [best practices](/best-practices/components) to get all the benefits of Atmos. For example, when using our [Terraform components](https://github.com/cloudposse/terraform-aws-components), we frequently use [Terraform Remote State](/core-concepts/share-data/remote-state) to retrieve the outputs from other components.
This works well when you use our components but less so when you operate in a "brownfield" environment, for example,
with an existing VPC, S3 bucket, or IAM role.
@@ -56,7 +56,7 @@ The `vpc` Terraform component needs the outputs from the `vpc-flow-logs-bucket`
configure [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html).
Let's redesign the example with the `vpc` and `vpc-flow-logs-bucket` components described in
-[Terraform Component Remote State](/core-concepts/components/terraform/remote-state) and configure the `static` remote state for
+[Terraform Component Remote State](/core-concepts/share-data/remote-state) and configure the `static` remote state for
the `vpc-flow-logs-bucket` component to use an existing S3 bucket.
## Examples
diff --git a/website/docs/core-concepts/components/terraform/state-backend.mdx b/website/docs/core-concepts/components/terraform/state-backend.mdx
index 383f63893..5e9aa2fc1 100644
--- a/website/docs/core-concepts/components/terraform/state-backend.mdx
+++ b/website/docs/core-concepts/components/terraform/state-backend.mdx
@@ -7,7 +7,7 @@ id: state-backend
import Intro from '@site/src/components/Intro'
-Atmos supports configuring [Terraform Backends](/core-concepts/components/terraform/backends) to define where Terraform stores its [state](https://developer.hashicorp.com/terraform/language/state), and [Remote State](/core-concepts/components/terraform/remote-state) to get the outputs of a [Terraform component](/core-concepts/components), provisioned in the same or a different [Atmos stack](/core-concepts/stacks), and use the outputs as inputs to another Atmos component.
+Atmos supports configuring [Terraform Backends](/core-concepts/components/terraform/backends) to define where Terraform stores its [state](https://developer.hashicorp.com/terraform/language/state), and [Remote State](/core-concepts/share-data/remote-state) to get the outputs of a [Terraform component](/core-concepts/components), provisioned in the same or a different [Atmos stack](/core-concepts/stacks), and use the outputs as inputs to another Atmos component.
Bear in mind that Atmos is simply managing the configuration of the Backend;
diff --git a/website/docs/core-concepts/projects/configuration/configuration.mdx b/website/docs/core-concepts/projects/configuration/configuration.mdx
index 386ecac67..0ed55b9fc 100644
--- a/website/docs/core-concepts/projects/configuration/configuration.mdx
+++ b/website/docs/core-concepts/projects/configuration/configuration.mdx
@@ -244,7 +244,7 @@ Initial Atmos configuration can be controlled by these environment variables:
## Special Considerations for Terraform Components
-If you are relying on Atmos discovering the `atmos.yaml` based on your current working directory (e.g. at the root of repository), it will work for the `atmos` CLI; however, it will **not work** for [Component Remote State](/core-concepts/components/terraform/remote-state) because it uses the [terraform-provider-utils](https://github.com/cloudposse/terraform-provider-utils) Terraform provider.
+If you are relying on Atmos discovering the `atmos.yaml` based on your current working directory (e.g. at the root of repository), it will work for the `atmos` CLI; however, it will **not work** for [Component Remote State](/core-concepts/share-data/remote-state) because it uses the [terraform-provider-utils](https://github.com/cloudposse/terraform-provider-utils) Terraform provider.
This is because Terraform executes provider from the component's folder (e.g. `components/terraform/vpc`), so it will no longer find the file in the root of the repository, since the working directory has changed.
diff --git a/website/docs/core-concepts/projects/configuration/stores.mdx b/website/docs/core-concepts/projects/configuration/stores.mdx
new file mode 100644
index 000000000..026a7e139
--- /dev/null
+++ b/website/docs/core-concepts/projects/configuration/stores.mdx
@@ -0,0 +1,117 @@
+---
+title: Configure Stores
+sidebar_position: 4
+sidebar_label: Configure Stores
+id: stores
+---
+import Intro from '@site/src/components/Intro'
+
+
+Atmos supports the concept of remote stores to facilitate the sharing of values between components or between
+some external process and a component. In `atmos`, values are saved to stores via
+[hooks](/core-concepts/stacks/hooks) and are read using the [!store](/core-concepts/stacks/yaml-functions/store.mdx)
+yaml function. Values can also be saved to stores from outside of `atmos`, for example, from a CI/CD pipeline or a
+script.
+
+Currently, the following stores are supported:
+
+- [AWS SSM Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)
+- [Artifactory](https://jfrog.com/artifactory/)
+
+
+Atmos stores are configured in the `atmos.yaml` file and available to use in stacks via the
+[store](/core-concepts/stacks/yaml-functions/store) YAML function.
+
+## CLI Configuration
+
+All of these settings should be configured in the [Atmos CLI Configuration](/cli/configuration) found in `atmos.yaml`.
+
+### Artifactory
+
+```yaml
+stores:
+ dev/artifactory:
+ type: artifactory
+ options:
+ url: https://mydevartifactory.jfrog.io/artifactory
+ repo_name: tfsharedstore
+
+ prod/artifactory:
+ type: artifactory
+ options:
+ url: https://myprodartifactory.jfrog.io/artifactory
+ repo_name: tfsharedstore
+ access_token: !env PROD_JFROG_ACCESS_TOKEN
+```
+
+
+ - `stores.[store_name]`
+ - This map key is the name of the store. It must be unique across all stores. This is how the store is referenced in the `store` function.
+
+ - `stores.[store_name].type`
+ - Must be set to `artifactory`
+
+ - `stores.[store_name].options`
+ - A map of options specific to the store type. For Artifactory, the following options are supported:
+
+ - `stores.[store_name].options.access_token (optional)`
+ - An access token to use for authentication. This is not recommended as it is less secure than using the
+ `JFROG_ACCESS_TOKEN` or `ARTIFACTORY_ACCESS_TOKEN` environment variables. See [Authentication](#authentication) below
+ for more information.
+
+ - `stores.[store_name].options.prefix (optional)`
+ - A prefix path that will be added to all keys stored or retreived from SSM Parameter Store. For example if the prefix
+ is `/atmos/infra-live/`, and if the stack is `plat-us2-dev`, the component is `vpc`, and the key is `vpc_id`, the full path
+ would be `/atmos/infra-live/plat-us2-dev/vpc/vpc_id`.
+
+ - `stores.[store_name].options.repo_name (required)`
+ - The name of the Artifactory repository to use.
+
+ - `stores.[store_name].options.url (required)`
+ - The URL of the Artifactory instance.
+
+
+#### Authentication
+
+The Artifactory store supports using an access token for authentication. The access token can be set directly in the
+`atmos.yaml` or via the `JFROG_ACCESS_TOKEN` or `ARTIFACTORY_ACCESS_TOKEN` environment variables.
+
+NOTE: It is not recommended to set the access token in plain text in `atmos.yaml` as it is not secure. Specifying the
+access token via config is allowed so that you can support the use case where you have multiple Artifactory stores
+in `atmos.yaml` and you need to specify different access tokens for each. In this case, you can use the `!env`
+YAML function to set the access token from an environment variable.
+
+### AWS SSM Parameter Store
+
+```yaml
+stores:
+ prod/ssm:
+ type: aws-ssm-parameter-store
+ options:
+ region: us-east-2
+```
+
+
+ - `stores.[store_name]`
+ - This map key is the name of the store. It must be unique across all stores. This is how the store is referenced in the `store` function.
+
+ - `stores.[store_name].type`
+ - Must be set to `aws-ssm-parameter-store`
+
+ - `stores.[store_name].options`
+ - A map of options specific to the store type. For AWS SSM Parameter Store, the following options are supported:
+
+ - `stores.[store_name].options.prefix (optional)`
+ - A prefix path that will be added to all keys stored or retreived from SSM Parameter Store. For example if the prefix
+ is `/atmos/infra-live/`, and if the stack is `plat-us2-dev`, the component is `vpc`, and the key is `vpc_id`, the full path
+ would be `/atmos/infra-live/plat-us2-dev/vpc/vpc_id`.
+
+ - `stores.[store_name].options.region (required)`
+ - The AWS region to use for the SSM Parameter Store.
+
+
+#### Authentication
+
+The AWS SSM Parameter Store supports the standard AWS methods for authentication and the `AWS_ACCESS_KEY_ID`,
+`AWS_SECRET_ACCESS_KEY`, and `AWS_SESSION_TOKEN` environment variables.
+
diff --git a/website/docs/core-concepts/components/terraform/remote-state.mdx b/website/docs/core-concepts/share-data/remote-state.mdx
similarity index 100%
rename from website/docs/core-concepts/components/terraform/remote-state.mdx
rename to website/docs/core-concepts/share-data/remote-state.mdx
diff --git a/website/docs/core-concepts/share-data/share-data.mdx b/website/docs/core-concepts/share-data/share-data.mdx
index 50ad3d9dc..cabf6edfb 100644
--- a/website/docs/core-concepts/share-data/share-data.mdx
+++ b/website/docs/core-concepts/share-data/share-data.mdx
@@ -14,10 +14,15 @@ import File from '@site/src/components/File'
import Note from '@site/src/components/Note'
-Breaking apart your infrastructure into loosely coupled components is a great way to manage complexity and reuse code. However, sometimes, you need to share data between components. In Atmos, you can easily share settings, configurations, and outputs between components and even tap into external data sources.
+Breaking up your infrastructure components into loosely coupled components is a great way to manage complexity and
+reuse code. However, these smaller components often lead to a situation where you need to share data between components.
+In Atmos, there are several ways you can easily share settings, configurations, and outputs among components and even
+tap into external data sources and stores.
-There are two ways to approach this: using native Terraform support for remote state to read outputs from other components or using template functions in stack configurations. In this chapter, you’ll learn how to share state between components within the same stack or even across different stacks.
+There are multiple ways to approach this: using native Terraform support for remote state to read outputs from other
+components or using template functions in stack configurations. In this chapter, you’ll learn how to share state between
+components within the same stack or even across different stacks.
- Why you might need to share data between components
@@ -26,6 +31,38 @@ There are two ways to approach this: using native Terraform support for remote s
+## Using YAML Functions
+
+### Function: `!store`
+
+The `!store` YAML function can read data from a remote store such as SSM Parameter Store or Artifactory.
+
+For example, we can read the `vpc_id` output of the `vpc` component in the current stack from the SSM Parameter Store
+configured in `atmos.yaml` as 'ssm/prod` simply by doing:
+
+```yaml
+components:
+ terraform:
+ cluster:
+ vars:
+ vpc_id: !store ssm/prod vpc vpc_id
+```
+
+To access the configuration of a component in a different stack, you can specify the stack name as the third argument.
+For example, here we're reading the `vpc_id` output of the `vpc` component in the `staging` stack:
+
+```yaml
+components:
+ terraform:
+ cluster:
+ vars:
+ vpc_id: !store ssm/prod vpc staging vpc_id
+```
+
+
+For more advanced examples, check out the `!store` yaml function documentation.
+Learn More
+
## Using Template Functions
@@ -173,5 +210,5 @@ resource "aws_network_acl" "default" {
Use the Terraform-native `remote-state` module to share data between components.
- Learn How
+ Learn How
diff --git a/website/docs/core-concepts/stacks/hooks.mdx b/website/docs/core-concepts/stacks/hooks.mdx
new file mode 100644
index 000000000..b570c8f9e
--- /dev/null
+++ b/website/docs/core-concepts/stacks/hooks.mdx
@@ -0,0 +1,70 @@
+---
+title: Manage Lifecycle Events with Hooks
+sidebar_position: 6
+sidebar_label: Manage Lifecycle Events with Hooks
+description: Use lifecycle hooks to take action at various points in the lifecycle of your components.
+id: hooks
+---
+import Terminal from '@site/src/components/Terminal'
+import Intro from '@site/src/components/Intro'
+import File from '@site/src/components/File'
+
+
+Atmos supports the ability to take action at various points in the lifecycle of your components. This is done by
+configuring the `hooks` section in your stack manifest for the component that you want to take action on.
+
+
+
+## Hooks Schema
+
+The `hooks` section schema is as follows:
+
+```yaml
+components:
+ terraform:
+ top-level-component1:
+ hooks:
+ store-outputs:
+ events:
+ - after-terraform-apply
+ command: store
+ name: prod/ssm
+ outputs:
+ vpc_id: .id
+```
+
+## Supported Lifecycle Events
+
+Atmos supports the following lifecycle events:
+
+- `after-terraform-apply` (this event is triggered after the `atmos terraform apply` or `atmos terraform deploy` command is run)
+
+## Supported Commands
+
+## store
+
+The `store` command is used to write data to a remote store.
+
+
+ - `hooks.[hook_name]`
+ - This map key is the name you want to give to the hook. This must be unique for each hook in the component.
+
+ - `hooks.[hook_name].events`
+ -
+ This is a list of [Supported Lifecycle Events](#supported-lifecycle-events) that should trigger running the command.
+
+
+ - `hooks.[hook_name].command`
+ - Must be set to `store`
+
+ - `hooks.[hook_name].name`
+ - The name of the store to use.
+
+- `hooks.[hook_name].outputs`
+ -
+ A map of values that will be written to the store under the key for this component. The key is the name of the key in
+ the store. The value is the value to write to the store. If the value begins with a dot (`.`), it will be treated as a
+ [Terraform output](https://developer.hashicorp.com/terraform/language/values/outputs) and the value will be retrieved
+ from the Terraform state for the current component.
+
+
diff --git a/website/docs/core-concepts/stacks/templates/functions/atmos.Component.mdx b/website/docs/core-concepts/stacks/templates/functions/atmos.Component.mdx
index 4e396c874..eb73f5271 100644
--- a/website/docs/core-concepts/stacks/templates/functions/atmos.Component.mdx
+++ b/website/docs/core-concepts/stacks/templates/functions/atmos.Component.mdx
@@ -37,7 +37,7 @@ Atmos component in a stack, and use it in `Go` templates in Atmos component conf
Using the `outputs` section in the `atmos.Component` command is an convenient way to read the outputs (remote state)
of a component in a stack directly in Atmos stack manifests. It is an alternative to using the `remote-state`
module and configuring Terraform/OpenTofu components to use the `remote-state` module as described in
- Component Remote State
+ Component Remote State
`attribute`
diff --git a/website/docs/core-concepts/stacks/yaml-functions/store.mdx b/website/docs/core-concepts/stacks/yaml-functions/store.mdx
new file mode 100644
index 000000000..a14eec13d
--- /dev/null
+++ b/website/docs/core-concepts/stacks/yaml-functions/store.mdx
@@ -0,0 +1,153 @@
+---
+title: "!store"
+sidebar_position: 4
+sidebar_label: "!store"
+description: Read a value from a store
+---
+import File from '@site/src/components/File'
+import Intro from '@site/src/components/Intro'
+import Terminal from '@site/src/components/Terminal'
+
+
+The `!store` YAML function allows reading the values from a remote [store](/core-concepts/projects/configuration/stores) (e.g. SSM Parameter Store, Artifactory, etc.)
+into Atmos stack manifests.
+
+
+## Usage
+
+The `!store` function can be called with either two or three parameters:
+
+```yaml
+ # Get the `key` from the store of a `component` in the current stack
+ !store
+
+ # Get the `key` from the store of a `component` in a different stack
+ !store
+```
+
+## Arguments
+
+
+ - `component`
+ - Atmos component name
+
+ - `stack`
+ - (optional) Atmos stack name
+
+ - `key`
+ - The key to read from the store
+
+
+
+:::tip
+You can use [Atmos Stack Manifest Templating](/core-concepts/stacks/templates) in the `!store` YAML function expressions.
+Atmos processes the templates first, and then executes the `!store` function, allowing you to provide the parameters to
+the function dynamically.
+:::
+
+## Examples
+
+
+```yaml
+components:
+ terraform:
+ my_lambda_component:
+ vars:
+ vpc_config:
+ security_group_id: !store security-group/lambda id
+ security_group_id2: !store security-group/lambda2 {{ .stack }} id
+ security_group_id3: !store security-group/lambda3 {{ .atmos_stack }} id
+```
+
+
+## Specifying Atmos `stack`
+
+If you call the `!store` function with three parameters, you need to specify the stack as the second argument.
+
+There are multiple ways you can specify the Atmos stack parameter in the `!terraform.output` function.
+
+### Hardcoded Stack Name
+
+Use it if you want to get a value from the store for a component from a different (well-known and static) stack.
+For example, you have a `tgw` component in a stack `plat-ue2-dev` that requires the `vpc_id` key from the `vpc` component from the stack `plat-ue2-prod`:
+
+```yaml title="plat-ue2-dev"
+ components:
+ terraform:
+ tgw:
+ vars:
+ vpc_id: !store vpc plat-ue2-prod vpc_id
+```
+
+### Reference the Current Stack Name
+
+Use the `.stack` (or `.atmos_stack`) template identifier to specify the same stack as the current component is in
+(for which the `!store` function is executed):
+
+```yaml
+ !store {{ .stack }}
+ !store {{ .atmos_stack }}
+```
+
+For example, you have a `tgw` component that requires the `vpc_id` key from the store for the `vpc` component in the same stack:
+
+```yaml
+ components:
+ terraform:
+ tgw:
+ vars:
+ vpc_id: !store vpc {{ .stack }} vpc_id
+```
+
+:::note Using the `.stack` or `.atmos_stack` template identifiers to specify the stack is the same as calling the
+`!store` function with two parameters without specifying the current stack, but without using `Go` templates. If you
+need to get a value from the store from a component in the current stack, using the `!store` function with two
+parameters is preferred because it has a simpler syntax and executes faster. :::
+
+### Use a Format Function
+
+Use the `printf` template function to construct stack names using static strings and dynamic identifiers.
+This is convenient when you want to override some identifiers in the stack name:
+
+```yaml
+ !store {{ printf "%s-%s-%s" .vars.tenant .vars.environment .vars.stage }}
+
+ !store {{ printf "plat-%s-prod" .vars.environment }}
+
+ !store {{ printf "%s-%s-%s" .settings.context.tenant .settings.context.region .settings.context.account }}
+```
+
+
+ - `
+
- Placeholder for an actual component name (e.g. `vpc`)
+ - ``
+ - Placeholder for an actual key (e.g. `subnet_ids`)
+
+
+
+For example, you have a `tgw` component deployed in the stack `plat-ue2-dev`. The `tgw` component requires the
+`vpc_id` key from the store for the `vpc` component from the same environment (`ue2`) and same stage (`dev`), but from a different
+tenant `net` (instead of `plat`):
+
+```yaml title="plat-ue2-dev"
+ components:
+ terraform:
+ tgw:
+ vars:
+ vpc_id: !store vpc {{ printf "net-%s-%s" .vars.environment .vars.stage }} vpc_id
+```
+
+:::tip Important
+ By using the `printf "%s-%s-%s"` function, you are constructing stack names using the stack context variables/identifiers.
+
+ For more information on Atmos stack names and how to define them, refer to `stacks.name_pattern` and `stacks.name_template`
+ sections in [`atmos.yaml` CLI config file](/cli/configuration/#stacks)
+:::
+
+## Considerations
+
+ - Using `!store` with secrets can expose sensitive data to standard output (stdout) in any commands that describe stacks or components.
+- When using `!store` with [`atmos describe affected`](/cli/commands/describe/affected), Atmos requires access to all referenced remote states.
+ If you operate with limited permissions (e.g., scoped to `dev`) and reference production stacks, the command will fail.
+- Be mindful of disaster recovery (DR) implications when using it across regions.
+- Consider cold-start scenarios: if the dependent component has not yet been provisioned, the value in the store may not yet be available and the `!store` function call will fail.
diff --git a/website/docs/core-concepts/stacks/yaml-functions/terraform.output.mdx b/website/docs/core-concepts/stacks/yaml-functions/terraform.output.mdx
index e7bf368a5..b8e94b298 100644
--- a/website/docs/core-concepts/stacks/yaml-functions/terraform.output.mdx
+++ b/website/docs/core-concepts/stacks/yaml-functions/terraform.output.mdx
@@ -9,7 +9,7 @@ import Intro from '@site/src/components/Intro'
import Terminal from '@site/src/components/Terminal'
-The `!terraform.output` YAML function allows reading the outputs ([remote state](/core-concepts/components/terraform/remote-state))
+The `!terraform.output` YAML function allows reading the outputs ([remote state](/core-concepts/share-data/remote-state))
of components directly in Atmos stack manifests.
@@ -251,13 +251,13 @@ vars:
## Considerations
- - Using `!terraform.output` with secrets can expose sensitive data to standard output (stdout) in any commands that describe stacks or components.
+ - Using `!terraform.output` with secrets can expose sensitive data to standard output (stdout) in any commands that describe stacks or components.
-- When using `!terraform.output` with [`atmos describe affected`](/cli/commands/describe/affected), Atmos requires access to all referenced remote states.
- If you operate with limited permissions (e.g., scoped to `dev`) and reference production stacks, the command will fail.
+- When using `!terraform.output` with [`atmos describe affected`](/cli/commands/describe/affected), Atmos requires access to all referenced remote states.
+ If you operate with limited permissions (e.g., scoped to `dev`) and reference production stacks, the command will fail.
-- Overusing the function within a stack to reference multiple components can significantly impact performance.
+- Overusing the function within a stack to reference multiple components can significantly impact performance.
-- Be mindful of disaster recovery (DR) implications when using it across regions.
+- Be mindful of disaster recovery (DR) implications when using it across regions.
- Consider cold-start scenarios: if the dependent component has not yet been provisioned, `terraform output` will fail.
diff --git a/website/docs/core-concepts/stacks/yaml-functions/yaml-functions.mdx b/website/docs/core-concepts/stacks/yaml-functions/yaml-functions.mdx
index 9dead5eab..6057be54e 100644
--- a/website/docs/core-concepts/stacks/yaml-functions/yaml-functions.mdx
+++ b/website/docs/core-concepts/stacks/yaml-functions/yaml-functions.mdx
@@ -26,9 +26,9 @@ Atmos detects the tags in the stack manifests and executes the corresponding fun
:::info
YAML supports three types of data: core, defined, and user-defined.
-- **Core types**: Universally supported, including floats, integers, strings, lists, and maps.
-- **Defined types**: Advanced types like binary data, specified in the YAML standard but not always supported.
-- **User-defined types**: Custom extensions for classes, structures, and functions. Atmos leverages user-defined types to implement its custom functions and extend YAML's capabilities.
+- **Core types**: Universally supported, including floats, integers, strings, lists, and maps.
+- **Defined types**: Advanced types like binary data, specified in the YAML standard but not always supported.
+- **User-defined types**: Custom extensions for classes, structures, and functions. Atmos leverages user-defined types to implement its custom functions and extend YAML's capabilities.
:::
## Use-cases
@@ -39,8 +39,8 @@ YAML supports three types of data: core, defined, and user-defined.
- The [__`!exec`__](/core-concepts/stacks/yaml-functions/exec) YAML function is used to execute shell scripts and assign
the results to the sections in Atmos stack manifests
- - The [__`!terraform.output`__](/core-concepts/stacks/yaml-functions/terraform.output) YAML function allows you to
- [access component outputs (remote state) directly within Atmos stack manifests](/core-concepts/components/terraform/remote-state).
+ - The [__`!terraform.output`__](/core-concepts/stacks/yaml-functions/terraform.output) YAML function allows you to
+ [access component outputs (remote state) directly within Atmos stack manifests](/core-concepts/share-data/remote-state).
Note that this requires initializing each component (`terraform init`), which downloads all Terraform providers and may significantly impact performance.
:::tip
diff --git a/website/docs/quick-start/advanced/configure-cli.mdx b/website/docs/quick-start/advanced/configure-cli.mdx
index 04a4c2078..d60cd5359 100644
--- a/website/docs/quick-start/advanced/configure-cli.mdx
+++ b/website/docs/quick-start/advanced/configure-cli.mdx
@@ -9,7 +9,7 @@ In the previous step, we've decided on the following:
- Use a monorepo to configure and provision two Terraform components into three AWS accounts and two AWS regions
- The filesystem layout for the infrastructure monorepo
-- To be able to use [Component Remote State](/core-concepts/components/terraform/remote-state), we put the `atmos.yaml` CLI config file
+- To be able to use [Component Remote State](/core-concepts/share-data/remote-state), we put the `atmos.yaml` CLI config file
into `/usr/local/etc/atmos/atmos.yaml` folder and set the ENV var `ATMOS_BASE_PATH` to point to the absolute path of the root of the repo
Next step is to configure `atmos.yaml`.
diff --git a/website/docs/quick-start/advanced/configure-repository.md b/website/docs/quick-start/advanced/configure-repository.md
index 656d4e372..c0851badd 100644
--- a/website/docs/quick-start/advanced/configure-repository.md
+++ b/website/docs/quick-start/advanced/configure-repository.md
@@ -78,7 +78,7 @@ The following example provides the simplest filesystem layout that Atmos can wor
## `atmos.yaml` CLI Config File Location
While placing `atmos.yaml` at the root of the repository will work for the `atmos` CLI, it will not work
-for [Component Remote State](/core-concepts/components/terraform/remote-state) because it uses
+for [Component Remote State](/core-concepts/share-data/remote-state) because it uses
the [terraform-provider-utils](https://github.com/cloudposse/terraform-provider-utils) Terraform provider. Terraform executes the provider from the
component's folder (e.g. `components/terraform/vpc`), and we don't want to replicate `atmos.yaml` into every component's folder.
@@ -103,7 +103,7 @@ This means that `atmos.yaml` file must be at a location in the file system where
Initial Atmos configuration can be controlled by these ENV vars:
- `ATMOS_CLI_CONFIG_PATH` - where to find `atmos.yaml`. Path to a folder where the `atmos.yaml` CLI config file is located (just the folder without
- the file name)
+ the file name)
- `ATMOS_BASE_PATH` - base path to `components` and `stacks` folders
diff --git a/website/docs/quick-start/advanced/vendor-components.mdx b/website/docs/quick-start/advanced/vendor-components.mdx
index 69001cc7a..80fd8c515 100644
--- a/website/docs/quick-start/advanced/vendor-components.mdx
+++ b/website/docs/quick-start/advanced/vendor-components.mdx
@@ -262,4 +262,4 @@ For this to work for both the `atmos` CLI and the Terraform `utils` provider, we
uses [Geodesic](https://github.com/cloudposse/geodesic) as the base Docker image. [Geodesic](https://github.com/cloudposse/geodesic) sets the ENV
var `ATMOS_BASE_PATH` automatically to the absolute path of the root of the repo on local host
-For a complete description of how Atmos components use remote state, refer to [Component Remote State](/core-concepts/components/terraform/remote-state).
+For a complete description of how Atmos components use remote state, refer to [Component Remote State](/core-concepts/share-data/remote-state).
diff --git a/website/docs/quick-start/simple/configure-cli.mdx b/website/docs/quick-start/simple/configure-cli.mdx
index aa7a9c8d3..9f03680d8 100644
--- a/website/docs/quick-start/simple/configure-cli.mdx
+++ b/website/docs/quick-start/simple/configure-cli.mdx
@@ -140,7 +140,7 @@ Well-known paths are how Atmos finds all your stack configurations, components,
### Config File Location
While placing `atmos.yaml` at the root of the repository will work for the `atmos` CLI, it will not work
-for [Component Remote State](/core-concepts/components/terraform/remote-state) because it uses
+for [Component Remote State](/core-concepts/share-data/remote-state) because it uses
the [terraform-provider-utils](https://github.com/cloudposse/terraform-provider-utils) Terraform provider. Terraform executes the provider from the
component's folder (e.g. `components/terraform/vpc`), and we don't want to replicate `atmos.yaml` into every component's folder.
diff --git a/website/docs/quick-start/simple/write-components.mdx b/website/docs/quick-start/simple/write-components.mdx
index 31bcbe3d8..b2085f149 100644
--- a/website/docs/quick-start/simple/write-components.mdx
+++ b/website/docs/quick-start/simple/write-components.mdx
@@ -109,7 +109,7 @@ The `versions.tf` file is where provider pinning is typically defined. Provider
### Implement `outputs.tf`
-The `outputs.tf` file is where, by convention in Terraform, you place any outputs you want to expose from your root module. Outputs are essential for passing state between your root modules and can be used in conjunction with [remote state](/core-concepts/components/terraform/remote-state) or the [Atmos function to retrieve the state](/core-concepts/stacks/templates/functions) of any other component.
+The `outputs.tf` file is where, by convention in Terraform, you place any outputs you want to expose from your root module. Outputs are essential for passing state between your root modules and can be used in conjunction with [remote state](/core-concepts/share-data/remote-state) or the [Atmos function to retrieve the state](/core-concepts/stacks/templates/functions) of any other component.
In object-oriented parlance, think of your outputs as the “public” attributes of the module that are intended to be accessed by other modules. This convention helps maintain clarity and organization within your Terraform configurations.