From ebf47a967de5760cd7eada49bc7a2e0b47bacd87 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jorge=20Rodr=C3=ADguez?= Date: Thu, 22 Feb 2024 12:03:04 +0000 Subject: [PATCH] docs: Update infrastructure-providers.mdx (#1524) --- website/docs/10_going-deeper/infrastructure-providers.mdx | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/website/docs/10_going-deeper/infrastructure-providers.mdx b/website/docs/10_going-deeper/infrastructure-providers.mdx index 677dd77c4..6f83e8bdd 100644 --- a/website/docs/10_going-deeper/infrastructure-providers.mdx +++ b/website/docs/10_going-deeper/infrastructure-providers.mdx @@ -4,10 +4,11 @@ import TerminalWindow from '@site/src/components/TerminalWindow/TerminalWindow' The providers are different implementations of the Booster runtime to allow Booster applications run on different cloud providers or services. They all implement the same interface, and the main idea behind the providers is that no matter what the developer chooses as backend, they won't need to know anything about the underlying infrastructure. -Currently, the Booster framework provides two fully working provider packages: +Currently, the Booster framework provides three provider packages: -- **framework-provider-aws-\*** - **framework-provider-azure-\*** +- **framework-provider-aws-\*** (deprecated - See [PR #1477](https://github.com/boostercloud/booster/pull/1477)) +- **framework-provider-local-\*** (for local testing) Booster uses sensible defaults, convention over configuration, and code inference to reduce dramatically the amount of configuration needed. However, there are some aspects that can't be inferred (like the application name) or the provider library used for each [environment](environment-configuration).