cloudposse · osterman · Aug 1, 2024 · Jul 26, 2024 · Jul 29, 2024 · Jul 30, 2024
diff --git a/docs/best-practices/best-practices.mdx b/docs/best-practices/best-practices.mdx
@@ -4,6 +4,8 @@ sidebar_label: Best Practices
 sidebar_class_name: hidden
 sidebar_position: 0
 description: Cloud Posse's Opinionated Reference Architecture Best Practices
+tags:
+  - best-practices
 ---
 
 > <q>Physics is the law, everything else is a recommendation.

diff --git a/docs/best-practices/developer/developer.mdx b/docs/best-practices/developer/developer.mdx
@@ -5,7 +5,6 @@ description: "We've written thousands of lines of code. These are our best pract
 tags:
   - best-practices
   - developer
-  - code
 ---
 import DocCardList from '@theme/DocCardList';
 import Intro from '@site/src/components/Intro';

diff --git a/docs/best-practices/developer/editor-config.mdx b/docs/best-practices/developer/editor-config.mdx
@@ -3,9 +3,8 @@ title: Editor Config Best Practices
 sidebar_label: Editor Config
 description: "The EditorConfig enables developers to define and maintain consistent coding styles between different editors and IDEs. It consists of a simple file format (`.editorconfig`) for defining coding styles such as tabs vs spaces. Most text editors support the format and adhere to defined styles. The config files are easily readable and they work nicely with version control systems."
 tags:
-  - code style
-  - formatting
-  - .editorconfig
+  - best-practices
+  - developer
 ---
 import Intro from '@site/src/components/Intro';
 

diff --git a/docs/best-practices/developer/github-sign-your-commits-with-ssh.mdx b/docs/best-practices/developer/github-sign-your-commits-with-ssh.mdx
@@ -1,6 +1,10 @@
 ---
 title: "Sign Your GitHub Commits with SSH"
 sidebar_label: "Sign GitHub Commits"
+tags:
+  - best-practices
+  - developer
+  - github
 ---
 
 If you are already using SSH to authenticate to GitHub, it is very easy to sign all your commits as well, as long as you have already installed Git 2.34.0 or later. (Note, there may be problems with OpenSSH 8.7. Use an earlier or later version. I have this working with OpenSSH 8.1p1.)

diff --git a/docs/best-practices/developer/makefile.mdx b/docs/best-practices/developer/makefile.mdx
@@ -3,9 +3,10 @@ title: "Makefile Best Practices"
 description: "We've written thousands of lines of Makefile. These are our best practices from the trenches."
 sidebar_label: Makefiles
 tags:
+  - developer
   - tool
   - make
-  - Makefile
+  - makefile
   - best-practices
 ---
 import Intro from '@site/src/components/Intro';

diff --git a/docs/best-practices/developer/markdown.mdx b/docs/best-practices/developer/markdown.mdx
@@ -2,6 +2,9 @@
 title: Markdown Best Practices
 sidebar_label: Markdown
 description: "Using Markdown is essential for clear communication on mediums such as GitHub, Slack or just plain text. Here are some of our recommendations on when to use certain conventions."
+tags:
+  - best-practices
+  - developer
 ---
 import Intro from '@site/src/components/Intro';
 

diff --git a/docs/best-practices/developer/password-management.mdx b/docs/best-practices/developer/password-management.mdx
@@ -2,6 +2,9 @@
 title: Password Management
 sidebar_label: Password Management
 description: ''
+tags:
+  - best-practices
+  - developer
 ---
 
 We strongly advise all companies to use "1Password for Teams" as their password management solution.

diff --git a/docs/best-practices/developer/semver.mdx b/docs/best-practices/developer/semver.mdx
@@ -3,7 +3,9 @@ title: Semantic Versioning
 sidebar_label: Semantic Versioning
 description: "Software versioning is the most widely adopted scheme for assigning unique version version numbers to software releases."
 tags:
-- semver
+  - semver
+  - best-practices
+  - developer
 ---
 
 We practice [Semantic Versioning](https://semver.org/) for all projects (e.g. GitHub Tags/Releases, Helm Charts, Terraform Modules, Docker Images). Using this versioning standard helps to reduce the entropy related to [Dependency Hell](https://en.wikipedia.org/wiki/Dependency_hell).

diff --git a/docs/best-practices/github/github-feature-branches.mdx b/docs/best-practices/github/github-feature-branches.mdx
@@ -2,6 +2,10 @@
 title: GitHub Feature Branches
 sidebar_label: Feature Branches
 description: "Use separate branches for developing specific features."
+tags:
+  - best-practices
+  - developer
+  - github
 ---
 import Intro from '@site/src/components/Intro'
 

diff --git a/docs/best-practices/github/github-pull-requests.mdx b/docs/best-practices/github/github-pull-requests.mdx
@@ -3,7 +3,9 @@ title: GitHub Pull Requests
 sidebar_label: Pull Requests
 description: Best practices using Pull Requests on GitHub.
 tags:
-- "Best Practices"
+  - best-practices
+  - developer
+  - github
 ---
 
 ## Submitting a Pull Request

diff --git a/docs/best-practices/github/github.mdx b/docs/best-practices/github/github.mdx
@@ -1,6 +1,10 @@
 ---
 title: "GitHub Best Practices"
 sidebar_label: "GitHub"
+tags:
+  - best-practices
+  - developer
+  - github
 ---
 
 ## Use `.gitignore`

diff --git a/docs/best-practices/terraform.mdx b/docs/best-practices/terraform.mdx
@@ -2,18 +2,18 @@
 title: "Terraform Best Practices"
 sidebar_label: "Terraform"
 description: "Our opinionated best-practices for Terraform"
-slug: "terraform-best-practices"
 tags:
-  - "Best Practices"
-  - "Terraform"
+  - best-practices
+  - terraform
+image: /assets/08bcd99-terraform.png
 ---
 
 ![Terraform](/assets/08bcd99-terraform.png)
 
 These are the *opinionated* best-practices we follow at Cloud Posse. They are inspired by years of experience writing terraform
 and borrow on the many other helpful resources like those by [HashiCorp](https://www.terraform.io/docs/cloud/guides/recommended-practices/index.html).
 
-See our general [Best Practices](/category/best-practices/) which also apply to Terraform.
+See our general [Best Practices](/best-practices/) which also apply to Terraform.
 
 ## Variables
 

diff --git a/docs/community/code-of-conduct.mdx b/docs/community/code-of-conduct.mdx
@@ -2,8 +2,8 @@
 title: Code of Conduct
 description: This is our Contributor Covenant Code of Conduct.
 tags:
-- open-source
-- agreement
+- community
+- code-of-conduct
 ---
 import Intro from '@site/src/components/Intro';
 

diff --git a/docs/community/contribute/automated-testing.mdx b/docs/community/contribute/automated-testing.mdx
@@ -2,6 +2,10 @@
 title: Terraform Automated Testing
 sidebar_label: Automated Testing
 description: 'Our automated testing strategy and resources'
+tags:
+  - community
+  - contribute
+  - developer
 ---
 import Intro from '@site/src/components/Intro';
 import Steps from '@site/src/components/Steps';

diff --git a/docs/community/contribute/code-reviews.mdx b/docs/community/contribute/code-reviews.mdx
@@ -2,12 +2,12 @@
 title: "Code Review Guidelines"
 description: "Code Review Guidelines"
 tags:
-  - "Best Practices"
-  - "Development"
+  - developer
+  - community
 ---
 import Steps from '@site/src/components/Steps';
 
-Here are some of our tips for conducting *Code Reviews* the SweetOps way. If you haven't already, become familiar with our [Best Practices](/category/best-practices/) and [Terraform Best Practices](/reference/best-practices/terraform-best-practices.md).
+Here are some of our tips for conducting *Code Reviews* the SweetOps way. If you haven't already, become familiar with our [Best Practices](/category/best-practices/) and [Terraform Best Practices](/best-practices/terraform).
 
 <Steps>
   1. Use the ["Suggest"](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request) feature as much as possible. This makes it quick and easy for the contributor to accept or dismiss the recommendations.

diff --git a/docs/community/contribute/contribute.mdx b/docs/community/contribute/contribute.mdx
@@ -2,6 +2,9 @@
 title: GitHub Contributors
 description: 'GitHub Contributors'
 sidebar_class_name: hidden
+tags:
+  - community
+  - contribute
 ---
 
 ## About

diff --git a/docs/community/contribute/contributor-tips.mdx b/docs/community/contribute/contributor-tips.mdx
@@ -2,6 +2,10 @@
 title: Contributor Tips & Tricks
 sidebar_label: Tips & Tricks
 description: 'Contributor Tips & Tricks'
+tags:
+  - tips-and-tricks
+  - contribute
+  - developer
 ---
 import Steps from '@site/src/components/Steps';
 

diff --git a/docs/community/contribute/faq.mdx b/docs/community/contribute/faq.mdx
@@ -2,6 +2,9 @@
 title: GitHub Contributors FAQ
 sidebar_label: FAQ
 description: 'GitHub Contributors FAQ'
+tags:
+  - faq
+  - contribute
 ---
 
 ## How do I see all open Pull Requests?
@@ -16,7 +19,7 @@ why something happened than blame or chastise our volunteers.
 
 ## What are your best-practices we should follow?
 
- See our  [Terraform Best Practices](/reference/best-practices/terraform-best-practices.md) and [Best Practices](/category/best-practices/). These are just some guidelines to follow and we're open to your feedback!
+ See our  [Terraform Best Practices](/best-practices/terraform) and [Best Practices](/best-practices/). These are just some guidelines to follow and we're open to your feedback!
 
 ## What benefits do I receive as a contributor?
 

diff --git a/docs/community/contribute/our-github.mdx b/docs/community/contribute/our-github.mdx
@@ -2,6 +2,8 @@
 title: "Our GitHub"
 description: "Information on how to collaborate with Cloud Posse"
 sidebar_position: 100
+tags:
+  - contribute
 ---
 import Steps from '@site/src/components/Steps';
 import Note from '@site/src/components/Note';

diff --git a/docs/community/office-hours.mdx b/docs/community/office-hours.mdx
@@ -4,6 +4,9 @@ sidebar_position: 3
 sidebar_label: Office Hours
 description: Office Hours with Cloud Posse
 id: office-hours
+tags:
+ - office-hours
+ - community
 ---
 import HubspotForm from 'react-hubspot-form'
 import { YouTubePlaylist } from '@codesweetly/react-youtube-playlist';

diff --git a/docs/community/slack.mdx b/docs/community/slack.mdx
@@ -4,6 +4,9 @@ sidebar_position: 3
 sidebar_label: Slack
 description: Cloud Posse's SweetOps Slack Community
 id: slack
+tags:
+  - slack
+  - community
 ---
 
 ## Join our Slack Community!

diff --git a/docs/community/support.mdx b/docs/community/support.mdx
@@ -2,6 +2,9 @@
 title: "Community Support"
 sidebar_label: "Support"
 sidebar_position: 100
+tags:
+  - support
+  - community
 ---
 
 # FAQ
@@ -12,7 +15,7 @@ Here are some quick answers to frequently asked questions. See also our [Trouble
 By far, the hardest part of being an open-source company is surviving the financial reality that very few companies ever pay for open source. Any financial contribution you can make helps us continue operating as a business, and we've made this easy through GitHub sponsorships.
 
 
-<iframe src="https://github.com/sponsors/cloudposse/card" title="Sponsor Cloud Posse" height="auto" width="100%" style={{border: 0}}></iframe>
+<iframe src="https://github.com/sponsors/cloudposse/card" title="Sponsor Cloud Posse" style={{border: 0}}></iframe>
 
 ## How do I request additional documentation?
 

diff --git a/docs/components/library/library.mdx b/docs/components/library/library.mdx
@@ -0,0 +1,15 @@
+---
+title: Terraform Components
+sidebar_label: Terraform Components
+sidebar_position: 0
+sidebar_class_name: hidden
+description: Libary of Terraform Root Module Components
+---
+import Intro from '@site/src/components/Intro';
+import DocCardList from '@theme/DocCardList';
+
+<Intro>
+  This is a libary of reusable Terraform "root module" components.
+</Intro>
+
+<DocCardList/>
diff --git a/docs/intro/for-agencies.mdx b/docs/intro/for-agencies.mdx
@@ -1,14 +1,26 @@
 ---
-title: Solutions For Agencies
-sidebar_label: For Agencies
+id: agencies
+title: Solutions For Agencies & Consultants
+sidebar_label: For Agencies & Consultants
 sidebar_position: 3
 sidebar_class_name: divider
-description: "Standardize your delivery."
+description: "Standardize your delivery"
+pagination_prev: intro/enterprises
+tags:
+- agency
 ---
 import Intro from '@site/src/components/Intro';
+import ActionCard from '@site/src/components/ActionCard';
+import PrimaryCTA from '@site/src/components/PrimaryCTA';
 
 <Intro>
   As an agency, moving quickly and serving numerous customers efficiently is a constant challenge. You've likely standardized your application stack language and framework—now it's time to standardize your infrastructure too.
 </Intro>
 
 By leveraging our reference architecture for AWS, you can focus more on solving your customers' problems and less on the details of the tooling itself. Customize it to your needs and develop common, reusable patterns across all your projects, scaling as necessary. With our component and module library, you won't need to worry about creating original Terraform code. Instead, you can immediately benefit from what's already built and supported by our community.
+
+<ActionCard title="What comes next?">
+  Now that you know the reference architecture will work for your customers, you're ready to get started with your first project.
+
+  <PrimaryCTA to="/layers/foundation">Next Step</PrimaryCTA>
+</ActionCard>
diff --git a/docs/intro/for-developers.mdx b/docs/intro/for-developers.mdx
@@ -3,11 +3,22 @@ id: developers
 title: "Solutions for Application Developers"
 sidebar_label: "For App Developers"
 sidebar_position: 4
+tags:
+- developers
 ---
 import Intro from '@site/src/components/Intro';
+import ActionCard from '@site/src/components/ActionCard';
+import PrimaryCTA from '@site/src/components/PrimaryCTA';
 
 <Intro>
 As a developer, leveraging the Cloud Posse reference architecture offers a robust framework for team collaboration, with thorough documentation and community support, saving time and effort while providing a strong foundation for your infrastructure.
 </Intro>
 
 If you're a developer, chances are you're entering a system already utilizing the Cloud Posse reference architecture set up by others in your organization, or you're being asked for advice on managing the next generation of your infrastructure. As a developer, you know the importance of using an established framework for any project—it provides consistent conventions, comprehensive documentation, and access to a supportive community. This is exactly what we offer. By tapping into the Cloud Posse reference architecture, you're building on a robust framework with thorough documentation, saving you significant time and effort in building your infrastructure. While there may be a learning curve, once you grasp it, you'll be far ahead of any company starting from scratch.
+
+
+<ActionCard title="What comes next?">
+  Now that you know what the reference architecture is for you, you're ready to get started with your first project.
+
+  <PrimaryCTA to="/layers/foundation">Next Step</PrimaryCTA>
+</ActionCard>
diff --git a/docs/intro/for-enterprises.mdx b/docs/intro/for-enterprises.mdx
@@ -4,8 +4,14 @@ title: Solutions for Enterprises
 sidebar_label: "For Enterprises"
 sidebar_position: 2
 description: Adopt a framework that streamlines enterprise infrastructure
+pagination_next: intro/agencies
+tags:
+- enterprise
 ---
 import Intro from '@site/src/components/Intro';
+import Steps from '@site/src/components/Steps';
+import ActionCard from '@site/src/components/ActionCard';
+import PrimaryCTA from '@site/src/components/PrimaryCTA';
 
 <Intro>
   As an enterprise, your monumental success over time has likely come at the significant cost of technical debt. As infrastructure grew organically, it's systems became complex and brittle. Many of those who built it, may no longer be around to support it. Now it's time to bring order to this chaos, thinking about the long-term success of your organization.
@@ -17,4 +23,38 @@ By adopting this reference architecture for AWS and the framework it's built upo
 - Security & Compliance
 - Scalability
 
+## Getting Started
+
+<Steps>
+1. ### Initiate a Proof of Concept (POC)
+   - Set up the reference architecture within your AWS organization
+   - Deploy a simple application to understand the setup and capabilities
+   - Evaluate the fit and identify any customization needs
+
+2. ### Assess Current Infrastructure
+   - Conduct an inventory of existing infrastructure
+   - Identify areas of technical debt and potential risks
+   - Map current infrastructure components to the reference architecture
+
+3. ### Plan the Adoption
+   - Develop a roadmap for the transition
+   - Define key milestones and deliverables
+   - Establish governance and compliance frameworks aligned with the reference architecture
+
+4. ### Pilot Phase
+   - Select a small, manageable project to pilot the framework
+   - Implement the reference architecture components and gather feedback
+   - Establish continuous integration and continuous deployment (CI/CD) pipelines
+
+5. ### Scale Implementation
+   - Roll out the reference architecture across multiple projects
+   - Train teams on new processes and tools
+   - Iterate on the architecture and processes based on real-world usage
+</Steps>
+
+<ActionCard title="What comes next?">
+  Now that you understand how the reference architecture can work for you, you're ready to get started with your first Proof of Concept.
+
+  <PrimaryCTA to="/layers/foundation">Next Step</PrimaryCTA>
+</ActionCard>