diff --git a/website/docusaurus.config.js b/website/docusaurus.config.js
index 63ea259a..058de1b5 100644
--- a/website/docusaurus.config.js
+++ b/website/docusaurus.config.js
@@ -11,6 +11,15 @@ module.exports = {
         image: 'img/eth-moby-logo.png',
     },
     scripts: ['https://buttons.github.io/buttons.js'],
+    i18n: {
+      defaultLocale: 'en',
+      locales: ['en', 'fr'],
+      localeConfigs: {
+        en: {
+          htmlLang: 'en-GB',
+        },
+      },
+    },
     themeConfig: {
         docs: {
             sidebar: {
@@ -30,6 +39,10 @@ module.exports = {
                     href: '/',
                     label: 'Get Started',
                     position: 'right',
+                },
+                {
+                  type: 'localeDropdown',
+                  position: 'left',
                 }
             ],
         },
diff --git a/website/i18n/fr/code.json b/website/i18n/fr/code.json
new file mode 100644
index 00000000..f86ecc5b
--- /dev/null
+++ b/website/i18n/fr/code.json
@@ -0,0 +1,440 @@
+{
+  "theme.ErrorPageContent.title": {
+    "message": "Cette page a planté.",
+    "description": "The title of the fallback page when the page crashed"
+  },
+  "theme.BackToTopButton.buttonAriaLabel": {
+    "message": "Retour au début de la page",
+    "description": "The ARIA label for the back to top button"
+  },
+  "theme.blog.archive.title": {
+    "message": "Archive",
+    "description": "The page & hero title of the blog archive page"
+  },
+  "theme.blog.archive.description": {
+    "message": "Archive",
+    "description": "The page & hero description of the blog archive page"
+  },
+  "theme.blog.paginator.navAriaLabel": {
+    "message": "Pagination de la liste des articles du blog",
+    "description": "The ARIA label for the blog pagination"
+  },
+  "theme.blog.paginator.newerEntries": {
+    "message": "Nouvelles entrées",
+    "description": "The label used to navigate to the newer blog posts page (previous page)"
+  },
+  "theme.blog.paginator.olderEntries": {
+    "message": "Anciennes entrées",
+    "description": "The label used to navigate to the older blog posts page (next page)"
+  },
+  "theme.blog.post.paginator.navAriaLabel": {
+    "message": "Pagination des articles du blog",
+    "description": "The ARIA label for the blog posts pagination"
+  },
+  "theme.blog.post.paginator.newerPost": {
+    "message": "Article plus récent",
+    "description": "The blog post button label to navigate to the newer/previous post"
+  },
+  "theme.blog.post.paginator.olderPost": {
+    "message": "Article plus ancien",
+    "description": "The blog post button label to navigate to the older/next post"
+  },
+  "theme.tags.tagsPageLink": {
+    "message": "Voir tous les tags",
+    "description": "The label of the link targeting the tag list page"
+  },
+  "theme.colorToggle.ariaLabel": {
+    "message": "Basculer entre le mode sombre et clair (actuellement {mode})",
+    "description": "The ARIA label for the navbar color mode toggle"
+  },
+  "theme.colorToggle.ariaLabel.mode.dark": {
+    "message": "mode sombre",
+    "description": "The name for the dark color mode"
+  },
+  "theme.colorToggle.ariaLabel.mode.light": {
+    "message": "mode clair",
+    "description": "The name for the light color mode"
+  },
+  "theme.docs.breadcrumbs.navAriaLabel": {
+    "message": "Fil d'Ariane",
+    "description": "The ARIA label for the breadcrumbs"
+  },
+  "theme.docs.DocCard.categoryDescription.plurals": {
+    "message": "1 élément|{count} éléments",
+    "description": "The default description for a category card in the generated index about how many items this category includes"
+  },
+  "theme.docs.paginator.navAriaLabel": {
+    "message": "Pages de documentation",
+    "description": "The ARIA label for the docs pagination"
+  },
+  "theme.docs.paginator.previous": {
+    "message": "Précédent",
+    "description": "The label used to navigate to the previous doc"
+  },
+  "theme.docs.paginator.next": {
+    "message": "Suivant",
+    "description": "The label used to navigate to the next doc"
+  },
+  "theme.docs.tagDocListPageTitle.nDocsTagged": {
+    "message": "Un document tagué|{count} documents tagués",
+    "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
+  },
+  "theme.docs.tagDocListPageTitle": {
+    "message": "{nDocsTagged} avec \"{tagName}\"",
+    "description": "The title of the page for a docs tag"
+  },
+  "theme.docs.versionBadge.label": {
+    "message": "Version: {versionLabel}"
+  },
+  "theme.docs.versions.unreleasedVersionLabel": {
+    "message": "Ceci est la documentation de la prochaine version {versionLabel} de {siteTitle}.",
+    "description": "The label used to tell the user that he's browsing an unreleased doc version"
+  },
+  "theme.docs.versions.unmaintainedVersionLabel": {
+    "message": "Ceci est la documentation de {siteTitle} {versionLabel}, qui n'est plus activement maintenue.",
+    "description": "The label used to tell the user that he's browsing an unmaintained doc version"
+  },
+  "theme.docs.versions.latestVersionSuggestionLabel": {
+    "message": "Pour une documentation à jour, consultez la {latestVersionLink} ({versionLabel}).",
+    "description": "The label used to tell the user to check the latest version"
+  },
+  "theme.docs.versions.latestVersionLinkLabel": {
+    "message": "dernière version",
+    "description": "The label used for the latest version suggestion link label"
+  },
+  "theme.common.editThisPage": {
+    "message": "Éditer cette page",
+    "description": "The link label to edit the current page"
+  },
+  "theme.common.headingLinkTitle": {
+    "message": "Lien direct vers {heading}",
+    "description": "Title for link to heading"
+  },
+  "theme.lastUpdated.atDate": {
+    "message": " le {date}",
+    "description": "The words used to describe on which date a page has been last updated"
+  },
+  "theme.lastUpdated.byUser": {
+    "message": " par {user}",
+    "description": "The words used to describe by who the page has been last updated"
+  },
+  "theme.lastUpdated.lastUpdatedAtBy": {
+    "message": "Dernière mise à jour{atDate}{byUser}",
+    "description": "The sentence used to display when a page has been last updated, and by who"
+  },
+  "theme.navbar.mobileVersionsDropdown.label": {
+    "message": "Versions",
+    "description": "The label for the navbar versions dropdown on mobile view"
+  },
+  "theme.NotFound.title": {
+    "message": "Page introuvable",
+    "description": "The title of the 404 page"
+  },
+  "theme.tags.tagsListLabel": {
+    "message": "Tags :",
+    "description": "The label alongside a tag list"
+  },
+  "theme.admonition.caution": {
+    "message": "attention",
+    "description": "The default label used for the Caution admonition (:::caution)"
+  },
+  "theme.admonition.danger": {
+    "message": "danger",
+    "description": "The default label used for the Danger admonition (:::danger)"
+  },
+  "theme.admonition.info": {
+    "message": "info",
+    "description": "The default label used for the Info admonition (:::info)"
+  },
+  "theme.admonition.note": {
+    "message": "remarque",
+    "description": "The default label used for the Note admonition (:::note)"
+  },
+  "theme.admonition.tip": {
+    "message": "astuce",
+    "description": "The default label used for the Tip admonition (:::tip)"
+  },
+  "theme.admonition.warning": {
+    "message": "attention",
+    "description": "The default label used for the Warning admonition (:::warning)"
+  },
+  "theme.AnnouncementBar.closeButtonAriaLabel": {
+    "message": "Fermer",
+    "description": "The ARIA label for close button of announcement bar"
+  },
+  "theme.blog.sidebar.navAriaLabel": {
+    "message": "Navigation article de blog récent",
+    "description": "The ARIA label for recent posts in the blog sidebar"
+  },
+  "theme.CodeBlock.copied": {
+    "message": "Copié",
+    "description": "The copied button label on code blocks"
+  },
+  "theme.CodeBlock.copyButtonAriaLabel": {
+    "message": "Copier le code",
+    "description": "The ARIA label for copy code blocks button"
+  },
+  "theme.CodeBlock.copy": {
+    "message": "Copier",
+    "description": "The copy button label on code blocks"
+  },
+  "theme.CodeBlock.wordWrapToggle": {
+    "message": "Activer/désactiver le retour à la ligne",
+    "description": "The title attribute for toggle word wrapping button of code block lines"
+  },
+  "theme.DocSidebarItem.expandCategoryAriaLabel": {
+    "message": "Développer la catégorie '{label}' de la barre latérale",
+    "description": "The ARIA label to expand the sidebar category"
+  },
+  "theme.DocSidebarItem.collapseCategoryAriaLabel": {
+    "message": "Réduire la catégorie '{label}' de la barre latérale",
+    "description": "The ARIA label to collapse the sidebar category"
+  },
+  "theme.NavBar.navAriaLabel": {
+    "message": "Main",
+    "description": "The ARIA label for the main navigation"
+  },
+  "theme.navbar.mobileLanguageDropdown.label": {
+    "message": "Langues",
+    "description": "The label for the mobile language switcher dropdown"
+  },
+  "theme.NotFound.p1": {
+    "message": "Nous n'avons pas trouvé ce que vous recherchez.",
+    "description": "The first paragraph of the 404 page"
+  },
+  "theme.NotFound.p2": {
+    "message": "Veuillez contacter le propriétaire du site qui vous a lié à l'URL d'origine et leur faire savoir que leur lien est cassé.",
+    "description": "The 2nd paragraph of the 404 page"
+  },
+  "theme.TOCCollapsible.toggleButtonLabel": {
+    "message": "Sur cette page",
+    "description": "The label used by the button on the collapsible TOC component"
+  },
+  "theme.blog.post.readMore": {
+    "message": "Lire plus",
+    "description": "The label used in blog post item excerpts to link to full blog posts"
+  },
+  "theme.blog.post.readMoreLabel": {
+    "message": "En savoir plus sur {title}",
+    "description": "The ARIA label for the link to full blog posts from excerpts"
+  },
+  "theme.blog.post.readingTime.plurals": {
+    "message": "Une minute de lecture|{readingTime} minutes de lecture",
+    "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
+  },
+  "theme.docs.breadcrumbs.home": {
+    "message": "Page d'accueil",
+    "description": "The ARIA label for the home page in the breadcrumbs"
+  },
+  "theme.docs.sidebar.collapseButtonTitle": {
+    "message": "Réduire le menu latéral",
+    "description": "The title attribute for collapse button of doc sidebar"
+  },
+  "theme.docs.sidebar.collapseButtonAriaLabel": {
+    "message": "Réduire le menu latéral",
+    "description": "The title attribute for collapse button of doc sidebar"
+  },
+  "theme.docs.sidebar.navAriaLabel": {
+    "message": "Docs sidebar",
+    "description": "The ARIA label for the sidebar navigation"
+  },
+  "theme.docs.sidebar.closeSidebarButtonAriaLabel": {
+    "message": "Fermer la barre de navigation",
+    "description": "The ARIA label for close button of mobile sidebar"
+  },
+  "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": {
+    "message": "← Retour au menu principal",
+    "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)"
+  },
+  "theme.docs.sidebar.toggleSidebarButtonAriaLabel": {
+    "message": "Ouvrir/fermer la barre de navigation",
+    "description": "The ARIA label for hamburger menu button of mobile navigation"
+  },
+  "theme.docs.sidebar.expandButtonTitle": {
+    "message": "Déplier le menu latéral",
+    "description": "The ARIA label and title attribute for expand button of doc sidebar"
+  },
+  "theme.docs.sidebar.expandButtonAriaLabel": {
+    "message": "Déplier le menu latéral",
+    "description": "The ARIA label and title attribute for expand button of doc sidebar"
+  },
+  "theme.SearchBar.seeAll": {
+    "message": "Voir les {count} résultats"
+  },
+  "theme.SearchPage.documentsFound.plurals": {
+    "message": "Un document trouvé|{count} documents trouvés",
+    "description": "Pluralized label for \"{count} documents found\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
+  },
+  "theme.SearchPage.existingResultsTitle": {
+    "message": "Résultats de recherche pour « {query} »",
+    "description": "The search page title for non-empty query"
+  },
+  "theme.SearchPage.emptyResultsTitle": {
+    "message": "Rechercher dans la documentation",
+    "description": "The search page title for empty query"
+  },
+  "theme.SearchPage.inputPlaceholder": {
+    "message": "Tapez votre recherche ici",
+    "description": "The placeholder for search page input"
+  },
+  "theme.SearchPage.inputLabel": {
+    "message": "Chercher",
+    "description": "The ARIA label for search page input"
+  },
+  "theme.SearchPage.algoliaLabel": {
+    "message": "Recherche par Algolia",
+    "description": "The ARIA label for Algolia mention"
+  },
+  "theme.SearchPage.noResultsText": {
+    "message": "Aucun résultat trouvé",
+    "description": "The paragraph for empty search result"
+  },
+  "theme.SearchPage.fetchingNewResults": {
+    "message": "Chargement de nouveaux résultats...",
+    "description": "The paragraph for fetching new search results"
+  },
+  "theme.SearchBar.label": {
+    "message": "Chercher",
+    "description": "The ARIA label and placeholder for search button"
+  },
+  "theme.SearchModal.searchBox.resetButtonTitle": {
+    "message": "Effacer la requête",
+    "description": "The label and ARIA label for search box reset button"
+  },
+  "theme.SearchModal.searchBox.cancelButtonText": {
+    "message": "Annuler",
+    "description": "The label and ARIA label for search box cancel button"
+  },
+  "theme.SearchModal.startScreen.recentSearchesTitle": {
+    "message": "Récemment",
+    "description": "The title for recent searches"
+  },
+  "theme.SearchModal.startScreen.noRecentSearchesText": {
+    "message": "Aucune recherche récente",
+    "description": "The text when no recent searches"
+  },
+  "theme.SearchModal.startScreen.saveRecentSearchButtonTitle": {
+    "message": "Sauvegarder cette recherche",
+    "description": "The label for save recent search button"
+  },
+  "theme.SearchModal.startScreen.removeRecentSearchButtonTitle": {
+    "message": "Supprimer cette recherche de l'historique",
+    "description": "The label for remove recent search button"
+  },
+  "theme.SearchModal.startScreen.favoriteSearchesTitle": {
+    "message": "Favoris",
+    "description": "The title for favorite searches"
+  },
+  "theme.SearchModal.startScreen.removeFavoriteSearchButtonTitle": {
+    "message": "Supprimer cette recherche des favoris",
+    "description": "The label for remove favorite search button"
+  },
+  "theme.SearchModal.errorScreen.titleText": {
+    "message": "Impossible de récupérer les résultats",
+    "description": "The title for error screen of search modal"
+  },
+  "theme.SearchModal.errorScreen.helpText": {
+    "message": "Vous pouvez vérifier votre connexion réseau.",
+    "description": "The help text for error screen of search modal"
+  },
+  "theme.SearchModal.footer.selectText": {
+    "message": "sélectionner",
+    "description": "The explanatory text of the action for the enter key"
+  },
+  "theme.SearchModal.footer.selectKeyAriaLabel": {
+    "message": "Touche Entrée",
+    "description": "The ARIA label for the Enter key button that makes the selection"
+  },
+  "theme.SearchModal.footer.navigateText": {
+    "message": "naviguer",
+    "description": "The explanatory text of the action for the Arrow up and Arrow down key"
+  },
+  "theme.SearchModal.footer.navigateUpKeyAriaLabel": {
+    "message": "Flèche vers le haut",
+    "description": "The ARIA label for the Arrow up key button that makes the navigation"
+  },
+  "theme.SearchModal.footer.navigateDownKeyAriaLabel": {
+    "message": "Flèche vers le bas",
+    "description": "The ARIA label for the Arrow down key button that makes the navigation"
+  },
+  "theme.SearchModal.footer.closeText": {
+    "message": "fermer",
+    "description": "The explanatory text of the action for Escape key"
+  },
+  "theme.SearchModal.footer.closeKeyAriaLabel": {
+    "message": "Touche Echap",
+    "description": "The ARIA label for the Escape key button that close the modal"
+  },
+  "theme.SearchModal.footer.searchByText": {
+    "message": "Recherche via",
+    "description": "The text explain that the search is making by Algolia"
+  },
+  "theme.SearchModal.noResultsScreen.noResultsText": {
+    "message": "Aucun résultat pour",
+    "description": "The text explains that there are no results for the following search"
+  },
+  "theme.SearchModal.noResultsScreen.suggestedQueryText": {
+    "message": "Essayez de chercher",
+    "description": "The text for the suggested query when no results are found for the following search"
+  },
+  "theme.SearchModal.noResultsScreen.reportMissingResultsText": {
+    "message": "Vous pensez que cette requête doit donner des résultats ?",
+    "description": "The text for the question where the user thinks there are missing results"
+  },
+  "theme.SearchModal.noResultsScreen.reportMissingResultsLinkText": {
+    "message": "Faites-le nous savoir.",
+    "description": "The text for the link to report missing results"
+  },
+  "theme.SearchModal.placeholder": {
+    "message": "Rechercher des docs",
+    "description": "The placeholder of the input of the DocSearch pop-up modal"
+  },
+  "theme.blog.post.plurals": {
+    "message": "Un article|{count} articles",
+    "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
+  },
+  "theme.blog.tagTitle": {
+    "message": "{nPosts} tagués avec « {tagName} »",
+    "description": "The title of the page for a blog tag"
+  },
+  "theme.blog.author.pageTitle": {
+    "message": "{authorName} - {nPosts}",
+    "description": "The title of the page for a blog author"
+  },
+  "theme.blog.authorsList.pageTitle": {
+    "message": "Authors",
+    "description": "The title of the authors page"
+  },
+  "theme.blog.authorsList.viewAll": {
+    "message": "View All Authors",
+    "description": "The label of the link targeting the blog authors page"
+  },
+  "theme.contentVisibility.unlistedBanner.title": {
+    "message": "Page non répertoriée",
+    "description": "The unlisted content banner title"
+  },
+  "theme.contentVisibility.unlistedBanner.message": {
+    "message": "Cette page n'est pas répertoriée. Les moteurs de recherche ne l'indexeront pas, et seuls les utilisateurs ayant un lien direct peuvent y accéder.",
+    "description": "The unlisted content banner message"
+  },
+  "theme.contentVisibility.draftBanner.title": {
+    "message": "Draft page",
+    "description": "The draft content banner title"
+  },
+  "theme.contentVisibility.draftBanner.message": {
+    "message": "This page is a draft. It will only be visible in dev and be excluded from the production build.",
+    "description": "The draft content banner message"
+  },
+  "theme.ErrorPageContent.tryAgain": {
+    "message": "Réessayer",
+    "description": "The label of the button to try again rendering when the React error boundary captures an error"
+  },
+  "theme.common.skipToMainContent": {
+    "message": "Aller au contenu principal",
+    "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation"
+  },
+  "theme.tags.tagsPageTitle": {
+    "message": "Tags",
+    "description": "The title of the tag list page"
+  }
+}
diff --git a/website/i18n/fr/docusaurus-plugin-content-blog/options.json b/website/i18n/fr/docusaurus-plugin-content-blog/options.json
new file mode 100644
index 00000000..9239ff70
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-blog/options.json
@@ -0,0 +1,14 @@
+{
+  "title": {
+    "message": "Blog",
+    "description": "The title for the blog used in SEO"
+  },
+  "description": {
+    "message": "Blog",
+    "description": "The description for the blog used in SEO"
+  },
+  "sidebar.title": {
+    "message": "Recent posts",
+    "description": "The label for the left sidebar"
+  }
+}
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current.json b/website/i18n/fr/docusaurus-plugin-content-docs/current.json
new file mode 100644
index 00000000..a8969095
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current.json
@@ -0,0 +1,18 @@
+{
+  "version.label": {
+    "message": "Next",
+    "description": "The label for version current"
+  },
+  "sidebar.docs.category.About": {
+    "message": "About",
+    "description": "The label for category About in sidebar docs"
+  },
+  "sidebar.docs.category.Usage": {
+    "message": "Usage",
+    "description": "The label for category Usage in sidebar docs"
+  },
+  "sidebar.docs.category.Support": {
+    "message": "Support",
+    "description": "The label for category Support in sidebar docs"
+  }
+}
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Acknowledgements.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Acknowledgements.md
new file mode 100644
index 00000000..493f6a17
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Acknowledgements.md
@@ -0,0 +1,9 @@
+---
+id: Acknowledgements
+title:  Acknowledgements
+sidebar_label: Acknowledgements
+---
+
+Parts of this guide are based on the Linux [guides](https://medium.com/@SomerEsat) written by [Somer Esat](https://twitter.com/SomerEsat).
+
+Without their previous work, this project would not exist.
\ No newline at end of file
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Changelog.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Changelog.md
new file mode 100644
index 00000000..7c5b3950
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Changelog.md
@@ -0,0 +1,1738 @@
+---
+id: Changelog
+title:  Changelog
+sidebar_label: Changelog
+---
+
+## Updating Eth Docker
+
+To update the components of Eth Docker, run from within its directory (`cd ~/eth-docker` by default):
+
+* `./ethd update`. This fetches new client version(s), a new Eth Docker, and updates `.env`, keeping your
+modifications. If you want to reset the source or binary build targets in `.env`, run `./ethd update --refresh-targets`
+instead.
+* `./ethd up` - use the new client version(s)
+
+> On 1/27/2022, Eth Docker's repository name changed. Everything should work as it did.
+> If you do wish to manually update your local reference, run `git remote set-url origin https://github.com/eth-educators/eth-docker.git`
+
+## v2.12.3.0 2024-09-20
+
+*This is a recommended release*
+
+Changes
+- Support Lido CSM module. Thanks @dgusakov, @vgorkavenko and @cnupy!
+- Add non-censoring Titan relay to mainnet default
+- Remove Eden relay from defaults
+- Do not switch Erigon repo to `erigontech/erigon`, yet, until images there contain `linux/amd64`
+
+Bug Fixes
+- `grafana.yml` and `grafana-cloud.yml` work with Docker `27.3.0` and later. Thanks u/ChewsMacRibs!
+- Fix incorrect method name during `./ethd update`. Thanks @kajeagentspi!
+
+## v2.12.2.0 2024-09-14
+
+*This is an optional release*
+
+Changes
+- Reth full sync now supports RocketPool, SSV and StakeWise by including their contracts for eth_getLogs / receipts.
+If you have an existing synced Reth, you'd need to make the change to `reth.toml` manually.
+- Erigon now defaults to the new `erigontech/erigon` repo and `latest` tag
+- Updated SSV dashboards
+- Add `./ethd keys count` command. Thanks @Hydepwns!
+- Persist Web3signer keys registered with Prysm
+- Use Go 1.23 for source builds
+- Support IPv6 for traefik
+- Besu sync mode and RPC API can be configured with `EL_EXTRAS`
+- Do not override Nethermind's `--Pruning.CacheMb`, as it was causing performance issues
+- Offer Prysm on ARM64
+- Offer Erigon on ARM64
+- Clarify the OS version nag
+- Source build for Teku and Besu uses Noble Numbat
+- Fresh sync of Besu, Geth or Nethermind prefers a Docker volume without `eth1` in the name
+
+Bug fixes
+- Only use `sudo` for `dkg_output` directory permission changes when needed. Thanks @jshufro!
+
+## v2.12.1.0 2024-08-10
+
+*This is an optional release*
+
+Changes
+- Support Erigon v3, including Caplin. To use Caplin, do not use an external CL
+- Use early attestations with `teku-vc-only.yml`. Thanks @b0a7!
+
+## v2.12.0.0 2024-08-08
+
+*This is a mandatory release for users of Lodestar 1.21.0 and above
+
+**Breaking** changes
+- Require Lodestar `1.21.0` or later
+
+## v2.11.2.0 2024-08-08
+
+*This is an optional release*
+
+Changes
+- Support IPv6 with Teku `24.8.0`
+- Users can freely set the Nethermind RPC namespaces through `EL_EXTRAS`
+
+## v2.11.1.0 2024-08-01
+
+*This is a mandatory release for users of Lighthouse Siren*
+
+Changes
+- Support Lighthouse Siren 2.0
+- Re-enable Nimbus in `./ethd config` when using SSV
+
+Bug fixes
+- Support the new Lighthouse dashboards
+
+## v2.11.0.1 2024-07-28
+
+*This is a recommended release for SSV node operators, with bug fixes*
+
+Changes
+- Switch Nimbus source build to alpine, from debian
+- Support RISC-V architecture in `./ethd config`. Thanks to @lazyprogrammerio and @haurog!
+
+Bug fixes
+- Remove Nimbus from SSV config query, see [Nimbus PR](https://github.com/status-im/nimbus-eth2/pull/6413). Thanks to
+@jwhelan72, celticwarrior on Ethstaker Discord!
+- Allow `--debug` on `./ethd keys import`
+- Only grep `~/.profile` if it exists
+- Recognize `arm64` (Mac M1/2/3) during `./ethd config`
+
+## v2.11.0.0 2024-07-13
+
+*This is an optional release with breaking changes*
+
+**Breaking** changes
+- Require Lodestar `1.20.0` or later when using `lodestar.yml`
+- Require Besu `24.7.0` or later when using `./ethd prune-besu`
+
+Changes
+- Replace Grandine deprecated `--builder-api-url` with `--builder-url`
+- Change Grandine default tag to `stable` from `latest`
+- Replace Besu deprecated `storage x-trie-log prune` with `storage trie-log prune`
+- Reenable Nethermind `--Pruning.CacheMb 4096` on systems with 32 GiB of RAM or more
+- `lodestar.yml` uses SSZ wire format and no longer specifies the REST namespace. Thanks @nflaig!
+
+## v2.10.1.0 2024-07-10
+
+*This is an optional release with new features*
+
+New features
+- Add `./ethd prune-reth` command. This should be run once only, when upgrading from Reth 1.0.0
+  - While Reth 1.0.0 is running and fully synced, `./ethd update`. This brings in Reth 1.0.1 but does not activate it yet.
+  - `./ethd prune-reth`. This prunes the Reth database, then restarts Reth. All other changed containers are also restarted.
+
+Bug fixes
+- `./ethd keys` works with Prysm again
+- Choosing "No" for SSV DKG during SSV configuration no longer quits ethd
+
+## v2.10.0.0 2024-06-23
+
+*This is an optional release with breaking changes*
+
+**Breaking** changes
+- Require Prysm `5.0.4` or later; enable Prysm QUIC port
+- Remove explicit Besu trie log limit, as it is default from `24.6.0` on
+
+New features
+- Add a `network` label to the metrics
+
+Bug fixes
+- Prysm can fetch genesis for Sepolia and Holešky
+- Nimbus EL builds and starts again
+- Resolve FromAsCasing warnings by Docker
+
+## v2.9.2.0 2024-06-11
+
+*This is an optional release with new features*
+
+New features
+- Support Nethermind `1.27`
+- Switch Lighthouse `latest-modern` to `latest`, to support `5.2.0`
+- Switch Erigon `stable` to `v2.60.1`. Please track Erigon versions manually 
+- Migrate existing Prysm and Lighthouse setups to new volume names matching the `cl-only.yml` ones
+- Enable separate static dir for Reth via `ANCIENT_DIR`
+- Source-build Besu with JDK 21
+- Grandine uses pruned storage when not configured as an archive node
+
+Bug fixes
+- DKG `chown` uses the owning user's group and only runs when required
+- Fix `./ethd sign-exit all` with web3signer and Prysm or Teku
+- Fix Lodestar source build
+- SSV config works on macOS
+
+## v2.9.1.0 2024-05-05
+
+*This is an optional release with new features*
+
+New features
+- Support the Grandine consensus layer client
+- Migrate to Loki 3. Caution that if you didn't update after 2024-04-09 and before 2024-05-01, this may require you to
+stop Loki with `./ethd stop Loki`, remove its volume with `docker volume rm eth-docker_loki-data` (adjust if the
+directory is not named `eth-docker`), and start again with `./ethd up`.
+
+Bug fixes
+- Reth DB conversion check works when there are two Reth on the machine
+- `./ethd install` doesn't throw an error if Docker is already installed and `pkg-config` is not
+
+## v2.9.0.0 2024-04-25
+
+*This is an optional release with new features*
+
+**Breaking** changes
+- Requires Nethermind `v1.26.0`
+
+New features
+- `./ethd prune-nethermind` will migrate the Nethermind DB to HalfPath on nodes with 32 GiB of RAM or more
+- Add discv5 to Reth
+
+Changes
+- Teku default heap to 6g
+- Lodestar default max peers to 100
+- Use Geth 1.14.0 defaults
+- Remove `./ethd prune-geth`
+
+Bug fixes
+- Do not default Besu to highspec on less than 64 GiB RAM, to avoid OOM errors
+- Do not downgrade the `.env` version
+- Fix Loki and prepare for Loki 3
+- Check for snap docker earlier
+
+## v2.8.0.0 2024-03-07
+
+*This is an optional release with new features*
+
+**Breaking** changes
+- Requires Besu `24.3.0`
+
+New features
+- Supports `./ethd prune-besu` for long-running Besu DBs, to one-off prune trie logs
+
+## v2.7.1.0 2024-03-06
+
+*This is an optional release with new features and bug fixes*
+
+New features
+- Supports Reth beta and prompts for resync if coming from Reth alpha
+- Update cadvisor to `0.49.1`
+- Update ethereum-metrics-exporter to `0.23.0`
+
+Bug fixes
+- Fix `HOST_IP` in `allin1.yml` files
+- Lodestar dashboard shows more metrics
+- Fix `./ethd config` not building
+- Besu high spec more reliably activates with 64 GiB RAM
+- `pull_policy: never` to avoid extraneous builds
+
+
+## v2.7.0.0 2024-02-24
+
+*This is an optional release with new features and bug fixes*
+
+**Breaking** changes
+- Breaks if `ext-network.yml` was changed. In this case please `mv ext-network.yml ~` it out to your home directory,
+try `./ethd update` again, and then `nano ext-network.yml` and re-apply the changes that were made, likely just the
+network name as `name: rocketpool_net` for reverse hybrid.
+- Drops support for Docker Compose V1
+- Drops support for automatically converting pre-merge (before September 2022) configurations
+- Requires Nethermind `v1.25.4` or later
+
+New features
+- Changed Lighthouse default max peers to 100, to match their 5.0.0 release
+- Lodestar flags updated to use the current convention. Thankls @nflaig!
+
+Bug fixes
+- Works more consistently on macOS. Thanks to @alindsilva and @toraonion for raising the issue and testing!
+- Fixed `prometheus-traefik.yml`
+- Fixed the jwt secret that `ethd config` queries for not being saved. Thanks @victorelec14!
+
+
+## v2.6.1.0 2024-02-10
+
+*This is an optional release with new features and bug fixes*
+
+New features
+- `./ethd sign-exit all` will sign a voluntary exit message for all loaded validators
+- `./ethd update --help` will print help specific to the `update` command
+- Added a Graffiti length check to `./ethd config`
+- Changed the CloudFlare DDNS container, as the old one is no longer supported upstream
+- Source compile for Geth, Prysm, Erigon and mev-boost uses Go 1.22
+
+Bug fixes
+- Updated Discord link. Thanks to @victorelec14 and @ymittal!
+- Fixed some typos. Thanks to @cristiantroy!
+- `./ethd keys delete` fixed
+- `./ethd keys prepare-address-change` works with Prysm
+- Nethermind dashboard fixed
+- SSV dashboard fixed
+- Fixed the pre-provisioned high memory alert in Grafana
+
+## v2.6.0.0 2024-01-25
+
+*This is an optional release with new features and bug fixes*
+
+**Breaking** changes
+- Requires Lighthouse 4.6.0 or later
+
+New features
+- Supports `./ethd prune-lighthouse` to prune Lighthouse state
+- Lighthouse VC will broadcast duties to all configured CLs, and uses v3 API for producing blocks
+- Besu on machines with 64 GiB of RAM or more will use the high spec flag
+- Added Bloxroute relay to default Holesky MEV config
+- Prysm uses 70 max peers by default
+- `./ethd config` offers a VC-only setup on Gnosis Chain. Thanks @haurog!
+- Remove Nethermind memory hints
+- Add network aliases to CLs, `${NETWORK}-consensus`. This can be useful in setups with multiple Eth Docker
+installations on one host, all connected to the same Docker overlay network
+- Changed Prometheus yq dependency to version `4`
+- Update Lodestar beacon `max-old-space-size` to `8192`. Thanks @nflaig!
+- Changed Teku default heap size to 5G
+- `./ethd keys` does some input vaidation on public keys and other user-supplied values
+
+Bug fixes
+- Nethermind prune no longer outputs an error message on Nethermind 1.25.0 and later
+- Added parameter to support Erigon 2.55 and later
+
+## v2.5.0.1 2023-12-31
+
+*This is an optional release with new features and bug fixes*
+
+- **Breaking** for Besu: Requires Besu 23.10.3
+- Besu will limit its trie logs, and on fresh sync heal its flat DB for better RPC performance
+- Besu source build uses Java 21 runtime (but continues to build with Java 17)
+- Additional pre-previsioned Grafana alerts: memory, CPU, out of memory (OOM) kill
+- Geth can keep its ancient directory on a separate path, see `ANCIENT_DIR` in `.env`
+- Logs dashboard works if the directory is not called `eth-docker`
+- Nethermind auto-prune uses 350 GiB threshold again on Gnosis Chain
+
+## v2.4.1.0 2023-12-29
+
+*This is an optional release with new features and bug fixes*
+
+- Fix `./ethd keys import` with unique passwords. Thanks @shamoya!
+- Fix Teku archive sync on Holesky
+- Nethermind auto-prune is network aware: Kicks off at 350 GiB mainnet, 50 GiB otherwise
+- Web3signer PostgreSQL migration to PG16 during `./ethd update`
+- Teku source build uses Java 21
+- Slightly less naive offline detection for `create-withdrawal-change.sh`
+
+## v2.4.0.0 2023-12-13
+
+*This is an optional release with new features and bug fixes for most users*  
+*It is mandatory for users of Teku 23.12.0 who do not wish to use checkpoint sync*
+
+- **Breaking** change: Teku without checkpoint sync (e.g. archive node) uses parameters that require Teku 23.12.0
+- Fixed checkpoint sync url query during `./ethd config`
+- `./ethd keys` can set individual Graffiti, as long as the client supports it
+- Prometheus instance hard-coded for easier use with dashboards that use instance
+- Added a pre-provisioned Grafana alert for disk space
+- Renamed Teku and Nimbus `-legacy.yml` files to `-allin1.yml`
+
+## v2.3.12.0 2023-12-04
+
+*This is an optional release with new features and bug fixes*
+
+- Fix Nimbus Web3signer wait loop
+- Add `./ethd space`
+- Add Eden relays to Holesky during `./ethd config`
+- `mev-boost` can be source-built
+- `./ethd update` can be `--non-interactive`
+- Support `ETHD_FRONTEND=noninteractive` as an alternative to `--non-interactive`
+
+## v2.3.11.0 2023-12-01
+
+*This is an optional release with new features and bug fixes*
+
+- New Nimbus and Teku deployments use a dedicated validator client service. Legacy deployments use the
+`nimbus-legacy.yml` and `teku-legacy.yml` files
+- Introduced a wait loop to Nimbus when using Web3signer, to work around a bug in Nimbus
+- Better handling of legacy `master` branch of Eth Docker
+
+## v2.3.10.0 2023-11-25
+
+*This is an optional release with new features and bug fixes*
+
+- Prometheus metrics collection improved. Scrape targets in `./prometheus/conf.d`, uses `yq` to merge
+`custom-prom.yml`. Default scrape interval 15s instead of 1m now possible because of this, which solves a whole bevvy
+of "No Data" in preloaded dashboards. Thanks to @aliask!
+- Preserve empty `RAPID_SYNC_URL` in `.env`
+- Extraneous web3signer messages during keyimport, when web3signer was not in use, resolved
+- `./ethd up <service-name>` supported
+- Version numbering will be semver-ish from here: World-shaking changes (think Ethereum merge) first digit, breaking
+changes second digit, enhancements third digit, bug fixes fourth digit.
+
+## v2.3.9 2023-11-15
+
+*This is an optional release with new features and bug fixes*
+
+- Eth Docker's version can be pinned in `.env`
+- Use new Teku v23.11.0 syntax. *Breaking* for any prior version.
+- Fix the `./ethd prune-geth` command
+- Additional IPv6 support for Lodestar, Geth and Erigon
+- Use .NET 8 for Nethermind source build
+- `default.env` defaults to Holesky testnet
+
+## v2.3.8 2023-11-08
+
+*This is an optional release with new features and bug fixes*
+
+- Fixed a **breaking** bug in `cl-traefik.yml` that impacted 2.3.7
+- Fix `./ethd keys delete all` when using Web3signer
+- `./ethd config` can now configure SSV for Holesky
+- Switched Prometheus to scrape by Docker labels
+- Added Web3signer dashboard
+- Fixed Nimbus dashboard provisioning
+- Running multiple RPC nodes connected to one central traefik is now easier. If that is your use case, set
+`EL_NODE=http://${NETWORK}-execution:8551` in `.env`. See the `ELCLIENT.yml` files for the alias this references.
+
+## v2.3.7 2023-11-02
+
+*This is an optional release with security relevant changes for traefik users*
+
+- **BREAKING** change for users who use traefik to access the execution client RPC API, consensus client REST
+API or execution client engine RPC API: The `el-traefik.yml`, `cl-traefik.yml` and `el-traefik.yml` files are
+now required for this. This was done to avoid host header attacks against users who just want to expose Grafana
+and may not have firewall rules in place to trusted source IPs.
+
+## v2.3.6 2023-11-02
+
+*This is an optional release with new features and bug fixes*
+
+- `./ethd keys send-exit` works with RocketPool reverse hybrid
+- Raise Loki ingestion limit. Thanks invis!
+- Prysm uses prysmctl for legacy exit method
+- Erigon source build uses Go 1.21
+- `./ethd config` offers Reth alpha
+- Send anonymized traefik usage
+- Fixes to `prysm-vc-only.yml`. Thanks @nflaig!
+- Scraping metrics centrally is now supported
+- RocketPool integration no longer adds `mev-boost.yml`
+- Error handler that restores `.env` if `./ethd update` fails. Thanks invis!
+- `./ethd config` is a little more visually consistent
+- On Ubuntu, use the `docker-compose-v2` package for Docker Compose upgrades
+- Lighthouse Siren fixed. Thanks @davidkassa!
+- Changed default checkpoint URL for Gnosis Chain
+- Added traefik labels to all `CL-CLIENT.yml` files
+
+## v2.3.5 2023-10-11
+
+*This is an optional release with new features and bug fixes*
+
+- Support for encrypted node key with an SSV node
+- Remove hard coded ancient barriers for Nethermind, use Nethermind defaults
+- Add tab completion for Linux systems. Thanks @jshufro!
+- Add support for Lighthouse Siren
+- Change Prometheus retention to 40d
+- Configurable Lodestar heap
+- Changed Teku and web3signer integration
+- Add QUIC port to Lighthouse
+- Support Nethermind v1.21
+
+## v2.3.4 2023-09-11
+
+*This is an optional release with new features and bug fixes*
+
+- `./ethd config` offers Holesky testnet
+- Geth fresh sync now uses PBSS
+- SSV supports MEV
+- SSV migrates to new jato-v2 testnet
+- Reth supports full node pruning
+- The `auto-prune.sh` script has been deprecated and will be removed with Dencun
+- New `./ethd keys sign-exit` command for use with clients' keymanager API
+- `./ethd config` prompts for MEV when using a RocketPool reverse hybrid setup. Thanks @haurog!
+- `./ethd keys import` knows about eth2-val-tools style `keys` and `secrets` folders. Thanks to Patches for prodding me!
+- Geth uses its down defaults for HTTP and WS API for easier override via `EL_EXTRAS`. Thanks @jiangbo0216!
+- Nimbus registers web3signer keys on startup
+- All-new support for custom testnets. Set `NETWORK` to a github repo containing the network repo such as `https://github.com/ethpandaops/dencun-testnet/tree/master/network-configs/devnet-8`. Thanks to Barnabas and client teams for the feature request!
+- Binary and source repos can now be specified in `.env`, to allow use of custom client repos for custom testnets.
+- Upgrading compose V1 to compose V2 no longer marks docker.io for deletion
+- New Nethermind executable name on source build. Thanks @rubo!
+
+## v2.3.3 2023-08-15
+
+*This is an optional release with new features and bug fixes*
+
+- Fixed an `./ethd terminate` edge case that would attempt to delete volumes in other stacks / directories
+- Improved web3signer support; work around a Teku bug
+- Support signing exit messages with keymanager API
+- Teku default heap reduced to 4g
+- Lodestar source build with node 20
+- Lodestar doppelganger flag adjusted. Thanks @nflaig!
+- cadvisor works on ARM64
+- Default to jato-v2 for new SSV setups
+- Geth source build with Go 1.21
+
+## v2.3.2 2023-08-03
+
+*This is an optional release with new features and bug fixes*
+
+- Update SSV and Nethermind dashboards
+- Update Prysm dashboards
+- Fix Teku VC connecting to Lighthouse CL
+- Fix Nimbus VC using MEV Boost
+- Remove dasel dependency from Nethermind
+- `./ethd config` on Gnosis Chain now offers Lodestar
+- Teku default heap changed to `-Xmx6g`
+- Fix a docker presence check on macOS
+- promtail can write to a remote Loki
+- Loki uses TSDB
+- Fix `./ethd install` failing when docker is not yet installed
+- Improvements to Geth and Lighthouse archive node options
+- Reth binary images supported
+- compose V1 EOS message
+- Lodestar forces validator files open in case of lingering lock files
+- `./ethd` can stop and restart individual services
+- Configurable traefik and ddns tags
+- Lighthouse source build uses maxperf. Thanks @jimmygchen!
+- Default NM source build target does not build rc targets. Thanks @nu404040!
+- ethdo script fixed when user used a 25th word. Thanks @valefar-on-discord!
+- Source builds updated to use Debian bookworm
+ 
+## v2.3.1 2023-05-17
+
+*This is an optional release with bug fixes*
+
+- Add web3signer support
+- Update SSV and Nethermind dashboards
+- IPv6 behind an `.env` var
+- Add logs dashboard. Thanks @gorillamania!
+- Nethermind works on ARM64. Thanks @natpicone!
+- New `prometheus-shared.yml`. Thanks @allen-pattern!
+- Fix `./ethd keys` when using RocketPool (reverse) hybrid
+
+## v2.3.0.1 2023-05-05
+
+*This is an optional release with bug fixes*
+
+- Support Nethermind 1.18 prune parameters; switch back to Hybrid prune
+- Graffiti string with `&` character survives `./ethd update`.
+- `./ethd update` checks for source-built clients and starts a fresh build
+- Use `--nat` for Lodestar and Reth
+- `deposit-cli.yml` no longer causes error messages during `./ethd update`.
+- Nethermind dasel dependency to `2.2.0`
+- Fix Lodestar and Nimbus entrypoint script on fresh sync
+
+## v2.3 2023-05-01
+
+*This is a recommended release*
+
+- Address findings from Sigma Prime security audit. Users of `ee-shared.yml` or `ee-traefik.yml` should pay particular attention.
+- Nethermind prune reduced to 2 threads, to have more headroom during sync committees.
+
+## v2.2.10.1 2023-04-29
+
+*This is an optional release*
+
+- validator exit for Lighthouse and Nimbus works if there are subdirectories in `.eth/validator_keys`. Thanks @gorillamania!
+- Add dashboard for Reth.
+- traefik revamped, new v6-aware DDNS provider for `traefik-cf.yml`.
+- Lighthouse enables v6 by default.
+
+## v2.2.10 2023-04-23
+
+*This is a mandatory release for users of Erigon, and optional for all others*
+
+- Support Erigon v2.43.0.
+- Initial work on IPv6 support.
+- Fix infinite loop in `create-withdrawal-change.sh`.
+- `traefik-cf.yml` can use more granular token permissions.
+ 
+## v2.2.9.5 2023-04-16
+
+*This is an optional release*
+
+- Use `docker compose` if it and `docker-compose` are installed.
+- Nethermind memory hint higher for 64 GiB RAM.
+- `create-withdrawal-change.sh` handles 12-word mnemonics.
+- Nimbus validator exit changed to fit new Nimbus behavior.
+- New command `./ethd keys sign-exit from-keystore [--offline]` to create pre-signed exit messages.
+
+## v2.2.9.4 2023-04-13
+
+*This is an optional release with bug fixes*
+
+- `./ethd resync-consensus` fixed for Prysm and Lodestar. Thanks @FloatingUpstream!
+- `./ethd resync-consensus` can now wipe Teku and Nimbus DB safely, without touching keys.
+- Prysm uses the gcr.io docker image registry. Thanks @FloatingUpstream!
+
+## v2.2.9.3 2023-04-12
+
+*This is an optional release*
+
+- Nethermind uses Full pruning mode instead of Hybrid.
+- Nethermind uses a lower memory hint to resolve OOM during prune.
+- Nethermind archive mode fixed.
+- Support for stake fish, staked.us and allnodes withdrawal change. Thanks @valefar!
+
+## v2.2.9.2 2023-04-09
+
+*This is an optional release with bug fixes*
+
+- Teku CL uses liveness tracking so doppelganger detection actually works.
+- ethdo now works with reverse hybrid setups, and similar setups where the CL is remote.
+- Undo a too-aggressive shell lint change, so saying "no" to Grafana works again.
+- Adjust Nethermind prune threshold to account for it using MB not MiB.
+- Adjust Nethermind memory hint in the hopes it won't OOM during prune.
+- Withdrawal credential change readme clarification around the mnemonic that is needed.
+
+## v2.2.9.1 2023-04-03
+
+*This is an optional release with bug fixes*
+
+- Support Teku doppelganger detection.
+- `./ethd keys send-address-change` counts unique addresses. Thanks to @valefar for fixing the logic!
+- Shell lint pass, which fixes a bug in `./ethd prune-nethermind` and `./ethd install`.
+
+## v2.2.9 2023-04-01
+
+*This is an optional release*
+
+- Add automatic pruning to Nethermind, controlled by `AUTOPRUNE_NM` in `.env`.
+
+## v2.2.8.7 2023-03-31
+
+*This is an optional release*
+
+- Remove soft max heap from Teku and Besu default JVM heap settings.
+- Resolve failure when upgrading from eth-docker 2.2.8.3 or earlier.
+- Dasel dependency upgraded to 2.1.2.
+- `reth.yml` sets the P2P port.
+- Remove check for apparmor.
+- `./ethd install` now requires Ubuntu 20.04 or later or Debian 10 or later.
+- `./ethd` warns the user if they are using Compose V1.
+
+## v2.2.8.6 2023-03-26
+
+*This is a bugfix release*
+
+- Fix a bug introduced in 2.2.8.5 that would break Graffiti with spaces. Thanks @nflaig!
+- New command `./ethd keys delete all`
+
+## v2.2.8.5 2023-03-25
+
+*This is an optional release*
+
+- Support client default graffiti - use this for Lodestar incentive
+- Add Lodestar beaconcha.in monitoring. Thanks @nflaig!
+- Keymanager works on ARM64
+- Rely on default ethdo timeout
+- Require 250 GiB free for Nethermind prune
+- Only overwrite `.env.bak` when there are changes
+- Warn user if `git pull` fails during `./ethd update`
+
+## v2.2.8.4 2023-03-21
+
+*This is a bugfix release*
+
+- Fix a bug during disk space check in `./ethd` introduced by 2.2.8.3
+
+## v2.2.8.3 2023-03-20
+
+*This is an optional release*
+
+- `./ethd resync-execution` and `./ethd resync-consensus` commands added
+- origins for Geth ws set to `*` - thanks @0xDualCube
+- Query for mnemonic passphrase when generating change message
+- Link to beaconcha.in broadcast tool
+
+## v2.2.8.2 2023-03-18
+
+*This is an optional release*
+
+- `./ethd` will check for free disk space and warn the user if it's running low
+- Fix and pin ethereum-metrics-exporter
+- Default Graffiti uses 🦉
+- Erigon supports larger return values for RocketPool >= 1.9
+- Erigon and Prysm source builds use Go 1.20
+- Lighthouse source build uses jemalloc and defaults to `stable` target
+- Prysm supports larger messages so credential change messages can be sent
+- Initial web3signer addition - not integrated with any clients
+- Don't query for mev-boost on Gnosis Chain
+- Add auth port for Reth
+
+## v2.2.8.1 2023-02-19
+
+*This is an optional release*
+
+- Online/offline withdrawal change workflow now actually works 😅
+- Geth will use PebbleDB on a fresh sync
+- Zhejiang testnet supported with Lodestar and Nethermind
+- Change default docker tag for Besu to `latest`
+- Remove legacy keyimport in preparation for security audit
+
+## v2.2.8 2023-02-08
+
+*This is an optional release*
+
+- Fixed `ethereum-metrics-exporter`. Thanks to @nflaig!
+- Added the ability to use client-default graffiti. Thanks to @nflaig!
+- `./ethd install` places the user into the `docker` group on Debian
+- Support online/offline withdrawal address change with ethdo. See `./ethd keys`
+
+## v2.2.7.1 2023-02-05
+
+*This is an optional release*
+
+- Nimbus engine connection defaults to `http://` instead of `ws://` on a fresh install
+- Teku uses the `MINIMAL` mode when running pruned
+- Nethermind workaround for Prysm, `--JsonRpc.MaxBatchSize 10000`
+- New command `./ethd cmd run deposit-cli-change` to prep for withdrawal credential changes, if deposit-cli.yml is included *and* deposit-cli supports this
+- Flashbots URL change
+- Check for apparmor on Ubuntu and Debian because of an issue with docker-ce 23.0.0
+- Pre-provision homestaking dashboard id 17846. Thanks to @gwenvador!
+
+## v2.2.7 2023-01-20
+
+*This is an optional release*
+
+- New advanced option `ARCHIVE_NODE` in `./env`. Caution that this can use upwards of 12TB of disk space.
+- Nethermind source build uses .NET 7.0
+- Lodestar prometheus scrape fixed. Thanks @nflaig!
+- Nethermind pruning requires 200 GiB free, down from 250 GiB
+- Extremely experimental support for Reth - it does not yet sync
+- `./ethd config` offers Erigon when running on Gnosis Chain
+- Update Nethermind's dasel dependency to v2.1.0
+- All source builds can now build from a tag, a branch, or a PR
+- `./ethd update` will also run `docker system prune --force` to remove dangling images and build caches
+
+## v2.2.6.3 2023-01-06
+
+*This is an optional release*
+
+- Update Ethereum metrics exporter dashboard to latest version
+- Add ultrasound relays to default list - thanks @JustinDrake! 🦇🔊
+- A few fixes for `./ethd` on macOS
+- `./ethd config` builds only once 😅
+- `./ethd update` now defaults to keeping changed build targets, and can reset them to defaults with `--refresh-targets`
+- New `./ethd keys create-prysm-wallet` for better UX when using Prysm
+- Remove return code workaround for Lodestar from key management script
+
+## v2.2.6.2 2022-12-31
+
+*This is an optional release*
+
+- Increase stop timeout for all EL to 5 minutes "just in case"
+- Explicit permissions for all scripts in Dockerfile - thanks to @mLewisLogic for finding a corner case!
+- Run Grafana as a non-root user
+- Explicit NAT method added to Besu - thanks to @dabauxi!
+- Update Nethermind's dasel dependency to v2.0.2
+
+## v2.2.6.1 2022-12-23
+
+*This is an optional release*
+
+- Add `--rpc-max-logs-range=65536` to `besu.yml` to support SSV and RocketPool out of the box
+- Fix handling of non-standard Docker data-root. Thanks to @mLewisLogic!
+- Added `grafana-rootless.yml` for use with rootless docker.
+
+## v2.2.6 2022-12-22
+
+*This is a required release for users of Nimbus, and optional for all others*
+
+- Support Nimbus v22.12.0. This is a breaking change, no prior releases of Nimbus are supported.
+- `./auto-prune.sh` now supports Nethermind. There is a risk that this breaks if Nethermind takes >24 hours to prune and the crontab is run every 24 hours. Feedback welcome.
+- `./auto-prune.sh` now supports `--threshold` and `--help`
+- Pruning logic now recognizes a non-standard docker `data-root` directory
+- Host map additional P2P ports for Erigon: It uses a separate port for each eth/xx P2P protocol.
+- Remove Nethermind metrics push timeout, as it no longer has a default pushgateway
+- Fix an issue that had `./ethd update` build everything twice
+
+## v2.2.5.1 2022-12-15
+
+*This is a required release for users of Teku, and optional for all others*
+
+- Fix Teku keymanager API cert. Thanks to @alepacheco for raising the issue!
+
+## v2.2.5 2022-12-08
+
+*This is a required release for users of Erigon and Nethermind, and optional for all others*
+
+- Experimental support for Nimbus EL client, `nimbus-el.yml`
+- Remove `--metrics.expensive` from Erigon for 2.31.0 support
+- Be more deliberate about versions of dasel, alpine and traefik
+
+## v2.2.4.2 2022-12-02
+
+*This is an optional release containing new features and bug fixes*
+
+- Nethermind source build fixed. Thanks @nu404040!
+- Reverted use of Bonsai snapshots. Note this can cause initial snap sync to fail, but should resolve failure after initial sync. Thanks @realsnick!
+- Replace `which` with `command -v` in `ethd` to get ready for Debian Bookworm
+- Add Nimbus as an option for Gnosis Chain during `./ethd config`
+- Image pull during `./ethd update` is more consistent
+
+## v2.2.4.1 2022-11-25
+
+*This is a required release for users of Nethermind on Gnosis, and optional for all others*
+
+- Let Nethermind determine sync mode based on chain
+- Better Nethermind prune. Thanks to Joe at RocketPool for the suggestion!
+- Some more cleanup around the removed Prometheus alert manager
+- Remove Akula 😭
+- Fix an error introduced by shell linting that caused `./ethd terminate` to fail - thanks to @RomanS-re!
+
+## v2.2.4 2022-11-22
+
+*This is a required release for users of Nethermind, and optional for all others*
+
+- Support Nethermind's new engine port parameters
+- `./ethd attach-geth` command, thanks to @ldub!
+- Removed Prometheus alert manager - it had been broken since before merge, may as well remove it 😅. Use Grafana's built-in alert manager instead, please
+- Sample config file for Grafana Cloud in `prometheus/custom-prom.yml.sample`
+- Require 250GiB free disk space before starting Nethermind prune
+
+## v2.2.3.1 2022-11-16
+
+*This is a required release for users of Akula, and optional for all others*
+
+- Fixed Akula source build
+- Lint pass on all shell scripts
+- Added deprecation warning to `./ethd keyimport`
+- Prometheus now uses default scrape time, so that `custom-prom.yml` will work with `grafana-cloud.yml`
+
+## v2.2.3 2022-11-13
+
+*This is an optional release containing new features*
+
+- Work around Lodestar's non-standard return codes on recipient/gas keymanager API
+- Keymanager API key import now waits up to 60s for slashing protection DB to be imported
+- Support Nethermind health checks
+- Use beaconcha.in's stat collector for Prysm and Nimbus
+
+## v2.2.2 2022-11-11
+
+*This is a required release for users of Erigon, and optional for all others*
+
+- Support Erigon 2.30.0's new `--externalcl` parameter. This is a breaking change, no prior versions of Erigon are supported.
+- Fix test for `custom-prom.yml` used in `grafana-cloud.yml`
+- Support MEV boost `-minbid`
+- Check for 125 GiB free disk space before Nethermind prune
+- Dynamic wait time when re-starting Nethermind for prune
+
+## v2.2.1 2022-11-05
+
+*This is a required release for users of Erigon, and optional for all others*
+
+- Support Erigon 2.29.0's new log level parameter
+- More debug info for sporadically failing Nethermind prune
+
+## v2.2.0 2022-11-02
+
+*This is a recommended release with new features and bug fixes*
+
+- Nethermind background pruning via `./ethd prune-nethermind`
+- Bonsai snapshots supported with Besu
+- New `grafana-cloud.yml` that uses `prometheus/custom-prom.yml`. Undocumented for now
+- Do not default to `--subscribe-all-subnets` for `cl-only.yml` files. Please add this via `CL_EXTRAS` if you need it
+- Geth always runs an `apk update` first when building the local image
+- Fix provisioning of the prysm_less_10 dashboard. Thanks @FloatingUpstream!
+- Support Teku's validator exit command for API managed keys
+- Better UX for initial Blox SSV setup
+- Add 30d retention period to Loki
+- Moved `CL_EXTRAS`, `EL_EXTRAS` and `VC-EXTRAS` into entrypoint script
+- `slasher.yml` files removed. If you used these, please use `CL_EXTRAS` instead
+- Enable pprof on Erigon and optimize for ZFS storage
+- cadvisor does housekeeping every 30s
+- Manifold removed from default relay list
+- Nimbus VC offered during `./ethd config`
+
+## v2.1.3 2022-10-06
+
+*This is an optional release with new features*
+
+- Erigon uses `stable` docker tag
+- Erigon uses `--batchSize 64m` in an attempt to squeeze it into 16 GiB 🐭
+- Besu defaults to `latest-openjdk-latest` and uses soft heap 3g
+- Add Nimbus vc-only yml
+- Erigon and Nimbus source builds default to latest release
+- Remove all `OVERRIDE_TTD` mentions
+
+## v2.1.2 2022-10-04
+
+*This is an optional release with bug fixes*
+
+- Prometheus now survives restarts 😅
+- Quiet Nethermind push failures
+- Fix `ext-network.yml` version
+
+## v2.1.1 2022-10-02
+
+*This is an optional release with new features and bug fixes*
+
+- Added `BESU_HEAP` and `TEKU_HEAP` variables to override the default Java heap settings for each
+- Fixed a bug in the new Prometheus yml handling for Nimbus and Teku
+- Default Besu to 5g heap, up from 4g
+- Source builds use Go 1.19
+- Add new dependency for Lighthouse source build
+
+## v2.1.0 2022-09-29
+
+*This is an optional release with new features*
+
+- `./ethd install` now installs docker-ce
+- `./ethd config` offers existing values
+- EL clients no longer start as root - chown no longer needed post-merge
+- `./ethd update` warns the user if there are uncommitted local changes
+
+## v2.0.4 2022-09-28
+
+*This is an optional release with new features*
+
+- Added a default dashboard for Nethermind
+- Reworked yml processing for Prometheus targets
+- Added cadvisor for Prometheus, and a dashboard for it
+- Added ethereum-metrics-exporter for Prometheus, and a dashboard for it
+- Added the ability to specify optional parameters for CL/EL/VC in `.env`
+
+## v2.0.3 2022-09-25
+
+*This is an optional release with new features*
+
+- Added Lodestar metrics, and a dashboard for it
+- Added `./ethd version` command. Thanks to @PabloCastellano!
+- Teku rapid sync works with checkpointz
+- Renamed all `client-base.yml` files to `client.yml` 
+- Lodestar supports validator exit again
+
+## v2.0.2 2022-09-16
+
+*This is a recommended release for post-merge changes*
+
+- Use current mev flag naming for Lighthouse VC
+- Improved key import
+- Fix Teku beacon stats API
+- Teku can recover from unclean shutdown
+- Add relay check to mev boost
+- Lodestar mev boost and rapid sync fixed
+- More resilient checkpoint sync for Nimbus and Lodestar
+- Use sudo automatically as and if needed
+- traefik metrics - thanks to @casualjim
+- Teku counts deposits more slowly to interop better with Besu
+- Teku -Xmx5g instead of -Xmx4g, to follow the team's recommendations
+- Teku voluntary exit works with API-imported keys
+- validator-backup command for Prysm
+- Erigon metrics fixed, thanks @casualjim
+- `MEV_NODE` and `MEV_DOCKER_TAG` survive updates
+- Config wizard no longer asks for override TTD
+
+## v2.0.1 2022-08-24
+
+*This is a recommended release for the Ethereum Merge*
+
+- Support Lodestar v1.0.0
+- Besu defaults to snap sync, after some issues with checkpoint sync
+- Use new engine API syntax for Prsym
+- Use fee recipient with Teku CL only
+- Use current SSV v2 repo
+- Fix Grafana for SSV v2
+- Fix default dashboard for Nimbus
+
+
+## v2.0.0 2022-08-22
+
+*This is a mandatory release for the Ethereum Merge*
+
+- **Breaking Change** docker-compose v1.28.0 or later is required. `./ethd update` will prompt for it
+- **Breaking Change** Erigon needs to be resynced from scratch and will run on its `alpha` branch. `./ethd update` will prompt for it
+- **Breaking Change** Infura "web3" fallback for the Execution Layer connection is no longer supported
+- Many changes to `.env`. `./ethd update` will make these automatically
+- merge-ready config with Engine API and JWT secret between Consensus Layer and Execution Layer
+- Doppelganger Protection supported
+- mev-boost supported
+- New `./ethd install` command that attempts to install prerequisites on Ubuntu
+- Support Sepolia and Ropsten testnets, in addition to Goerli
+- Ability to import slashing protection DB
+- Better checks for prerequisites existing in `./ethd`. Thanks to joeytwiddle
+- Automatic `sudo` in `./ethd` if required. Thanks to joeytwiddle
+- Keymanager support for Lodestar
+- Besu defaults to checkpoint sync
+- Teku VC supports failover CLs
+
+## v1.8.8 2022-07-13
+
+*This is an optional release, that contains new features and bug fixes*
+
+- `./ethd` now works with docker-ce and compose plugin, including on Debian 11
+- Support spaces in Graffiti
+- Fix a regression in `./ethd prune-geth`
+
+## v1.8.7 2022-06-25
+
+*This is an optional release, that contains new features and bug fixes*
+
+- `./ethd update` now always runs the latest version of itself
+- `./ethd update` aborts when a user chooses "Cancel" on the fee recipient screen
+- `FEE_RECIPIENT` variable in `.env` instead of `REWARDS_TO`
+- Improve Lighthouse memory allocation defaults
+- Gracefully handle `sudo ./ethd update`
+- Automatic switch to the `rpc-nodes` branch is clearer
+- Keep Teku key management API TLS cert from being deleted all the time
+
+## v1.8.6 2022-06-14
+
+*This is an optional release, that contains new features and bug fixes*
+
+- `./ethd prune-geth` now correctly asks for confirmation
+- `./ethd update` will nag users about running both a CL and EL. Nag screen can be overridden via `.env` setting
+
+## v1.8.5 2022-06-11
+
+*This is an optional release, that contains new features and bug fixes*
+
+- Keep Lodestar build targets
+- Suppress Nethermind JSON RPC logs
+- Fix genesis download for Prysm on Prater
+- Change SSV node default ports
+- Hardcode `./.eth` as the directory for key files
+- Fix help URL displayed during `./ethd config`
+- Fix Lighthouse validator startup
+- Rename Prater to Görli
+- Stop tracking changes to `ext-network.yml`
+- Improve peer count adjustment, a MIN can now be set
+- Change default Teku peers to 100
+- Verify rewards address for correctness on `./ethd update`
+- Better UX / question flow during `./ethd config`
+- Clearer warning not to `./ethd restart` without a rewards address
+- Besu now defaults to snap sync
+- `CL_NODE` will now inherit the `CC_NODE` setting on `./ethd update`
+
+## v1.8.4 2022-05-24
+
+*This is an optional release, that contains new features and bug fixes*
+
+- **Breaking change**: OpenEthereum `oe.yml` has been removed, now that OpenEthereum is officially end of support and its repo has been archived
+- Fixed ethd to once more work on macOS
+- Besu is now offered as a choice on ARM64
+- All clients that support it now use `--suggested-fee-recipient`
+- Changed language of message box that prompts for fee recipient, to be clearer
+- Added `validator-list` command
+
+## v1.8.3 2022-05-19
+
+*This is an optional release, that contains new features and bug fixes*
+
+- Highly, highly experimental support for Akula. Do not use in production
+- A few fixes around CL/EL NewSpeak
+- Lodestar can import multiple keystores non-interactively
+- staking-deposit-cli moved to Python 3.10
+- `./ethd update` prompts for an Ethereum rewards address for priority fees and MEV, to be used post-merge. Currently only and exclusively actually being used by `lh-validator.yml`
+
+## v1.8.2 2022-05-07
+
+*This is an optional update, that contains new features*
+
+- Experimental support for Prysm rapid sync
+- Use JDK 17 to build Besu from source
+- Remove consensus-only files and keep them in `rpc-nodes` branch only. Ditto remove old grafana yml files. This is meant to make the main branch more approachable.
+
+## v1.8.1 2022-04-26
+
+*This is an optional update, that contains new features*
+
+- Remove advanced yml files from `main` branch. Please use the `rpc-nodes` branch if you are running a distributed
+environment.
+- `./ethd update` removes and renames yml files in `COMPOSE_FILE` and will automatically switch the branch for users
+of advanced yml files.
+
+## v1.8 2022-04-21
+
+*This is an optional update, that contains new features*
+
+- Close Promtail/Loki ports
+- Support Gnosis Beacon Chain with `./ethd config`
+
+## v1.7.8 2022-04-16
+
+*This is an optional update, that contains new features*
+
+- Prometheus metrics for all execution clients
+- Remove node dashboard because it had Grafana alerts
+- Update RocketPool integration for RocketPool 1.3.0
+- `*-consensus.yml` now subscribe to all subnets, which is helpful for staking at scale
+- Add `prometheus-traefik.yml` for use with federation or just to make it available via https://
+- Support Blox SSV 0.1.11 and later
+
+## v1.7.7.2 2022-03-28
+
+
+- Switch to Go 1.18 for source builds
+- Fix Nimbus Gnosis source build
+
+## v1.7.7.1 2022-03-22
+
+
+- Lighthouse default peers 80 to fit new guidance
+- Bonsai tries for Besu with GA flag - thanks to @JustNotHelpful
+- Nimbus switched back to use ws:// for web3 connections
+- Prysm source build no longer attempts to build standalone slasher
+
+## v1.7.7 2022-03-14
+
+*This is an optional update, that contains new features*
+
+* Breaking change: prysm-consensus-rest.yml removed, and prysm-consensus.yml changed to only support REST. Remote RPC is no longer available.
+* Remove deprecated Nimbus RPC and use REST
+* Improve Nimbus source build; support building Nimbus for Gnosis Chain
+
+## v1.7.6.1 2022-03-05
+
+*This is an optional update, that contains new features*
+
+- New `teku-stats.yml` to support beaconcha.in stats with Teku
+- Better `tzdata` installation on Debian images
+- Logs available in Grafana via Loki
+
+## v1.7.6 2022-02-16
+
+*This is an optional update, that contains new features and bugfixes*
+
+- `./ethd update` no longer overwrites an empty `GRAFFITI`
+- Support for Nimbus rapid sync
+- Support for Nimbus CORS on keymanager (experimental)
+- Switched default Nimbus web3 URL from ws:// to http://
+
+## v1.7.5.1 2022-02-09
+
+*This is an optional update, that contains new features*
+
+- `./ethd prune-geth` will now restart Geth after prune. Thanks to Joe @ RocketPool for the idea!
+- The `auto-prune.sh` script no longer asks for user input
+
+## v1.7.4.4 2022-02-08
+
+*This is an optional update, that contains new features and bug fixes*
+
+- `prysm-consensus.yml` now only exposes REST, no longer gRPC. This is a breaking change if you are using a remote Prysm validator with it!
+- Fixed Lodestar rapid sync to use the new format
+- Fixed Lodestar execution client connection to use the new format
+- Nethermind log level fixed
+- `./ethd update` no longer shows an error when coming from an older version of eth-docker
+
+## v1.7.4.3 2022-02-05
+
+*This is an optional update, that contains new features*
+
+- Support staking-deposit-cli v2.0.0
+
+## v1.7.4.2 2022-02-04
+
+*This is an optional update, that contains new features*
+
+- Experimental support for the standardized key management API, exposed on localhost port `7500` with `consensus-keyapi-localport.yml` or `validator-keyapi-localport.yml`, depending on whether the specific client has a separate validator container.
+- Warn when Ubuntu "snap" docker is found
+- Default to Lighthouse `latest-modern` image
+- Nethermind no longer uses an ancient barrier. This means other clients can sync from it.
+
+## v1.7.4.1 2022-02-01
+
+*This is a bugfix update*
+
+- Grafana dashboards retain their variables across restart
+- `./ethd config` and `./ethd update` now warn when a snap install of Docker is found
+
+## v1.7.4 2022-01-30
+
+*This is an optional update, that contains new features*
+
+- Fixed Lodestar
+- Initial support for integration with Wagyu installer
+- `./ethd keyimport` command
+- Experimental support for Key Manager API on Nimbus, on `127.0.0.1:5053`
+
+## v1.7.3 2022-01-29
+
+*This is an optional update, that contains new features*
+
+- MacOS support. Thanks to suburbandad!
+- Nethermind no longer uses ancient barriers, so other clients can sync from it
+- CORS origin * throughout so Metamask works
+- geth-prune now wants 40GB free instead of 50GB
+- Improved Besu source build
+
+## v1.7.2.5 2022-01-21
+
+*This is a bugfix update, and also contains new features*
+
+* Fix Lodestar validator startup path - yep that means no-one was running it :)
+* Remove /etc/timezone throughout - the `-notz.yml` files should no longer be used on Amazon Linux 2
+* Added Nethermind as an option on arm64 
+
+## v1.7.2.4 2022-01-14
+
+*This is an optional update, that contains new features*
+
+* Support Nimbus validator monitor
+* Improved `./ethd config` for RocketPool
+
+## v1.7.2.1 2022-01-14
+
+*This is an optional update, that contains new features*
+
+* Revamped `./ethd config` for easier integration with RocketPool and Blox
+
+## v1.7.1 2022-01-12
+
+*This is an optional update, that contains new features*
+
+* Added a Grafana dashboard for Besu.
+
+## v1.7.0 2022-01-11
+
+*This is an optional update, that contains new features*
+
+* Overhauled the Grafana dashboards. Please report issues.
+
+## v1.6.9 2022-01-10
+
+*This is an optional update, that contains new features*
+
+* Support running blox-ssv node via eth-docker
+
+## v1.6.8 2022-01-07
+
+*This is an optional update, that contains new features and bug fixes*
+
+* Traefik web proxy no longer uses wild card certs
+* Nimbus no longer uses `--subscribe-all-subnets` when run as a consensus client only
+* Fixed a permissions issue with `./ethd prune-geth`
+
+## v1.6.7 2022-01-02
+
+*This is an optional update, that contains new features and bug fixes*
+
+* Doppelganger protection turned off by default
+* Lighthouse Rapid Sync now works with Grafana enabled
+
+## v1.6.5 2021-12-22
+
+*This is an optional update, that contains new features*
+
+* `./ethd config` now supports Lodestar
+* Source builds for Geth and Erigon switched to Go 1.17 from Go 1.16
+
+## v1.6.4 2021-12-17
+
+*This is an optional update, that contains new features*
+
+* Prep for Nimbus rapid sync
+* `./ethd config` now queries for rapid sync on Lighthouse
+* Erigon supports `eth_sendRawTransaction`
+
+## v1.6.3 2021-12-06
+
+*This is an optional update, that contains new features and bug fixes*
+
+* Fixed a bug in `lh-validator.yml` that would prevent the image building
+* Move LodeStar source build to node.js 16
+* Support for LodeStar consensus client only and LodeStar validator client only
+* Lodestar REST API also on port 5052
+
+## v1.6.2 2021-12-06
+
+*This is an optional update, that contains new features and bug fixes*
+
+* Fixed a permissions bug with `prysm-web.yml` introduced in 1.6
+* Consensus REST API consistently on port 5052 for compatibility with RocketPool
+
+## v1.6.1 2021-11-27
+
+*This is an optional update, that contains new features*
+
+* Added `nimbus-consensus.yml` to run Nimbus as a remote consensus client
+* Changed `prysm-consensus.yml` to expose the standard REST API via https://
+* Changed Nethermind source compile to use .NET 6.0
+* Restricted Besu Java heap to 4 GiB
+
+## v1.6 2021-11-20
+
+*This is an optional update, that contains new features and bug fixes*
+
+* Support the latest Besu release
+* All intermediary scripts that migrate from pre-v1.x setups have been removed. This is a breaking change
+  if you are coming from a v0.x release.
+* `-shared.yml` files for consensus clients, just for 0neInfra :)
+
+## v1.5.10 2021-11-10
+
+*This is an optional update, that contains new features and bug fixes*
+
+* Besu defaults to Bonsai tries. This will require a complete resync.
+* Teku validator client uses `--network=auto` flag
+* Besu allows Metamask connection
+* Added `./ethd rocketeer` to change RocketPool config when running hybrid mode
+* Auto-prune permissions issue resolved
+* `./ethd update` keeps `LS_RAPID_SYNC`
+
+## v1.5.9 2021-10-11
+
+*This is an optional update, that contains new features*
+
+* New docker logging configuration - now when you run out of space, it'll be Geth, not Traefik debug logs
+* Support for Lodestar's checkpoint sync via `LS_RAPID_SYNC`
+* Fixed Lodestar's binary and source builds: The location of the binary changed
+
+## v1.5.8 2021-10-09
+
+*This is a bugfix update*
+
+* beacon-chain stats work with the split consensus/validator Lighthouse. Thanks to Faisal Moledina.
+
+## v1.5.7 2021-10-09
+
+*This is a bugfix update*
+
+* `./ethd prune-geth` no longer tries to allocate a TTY, which could cause it to fail.
+
+## v1.5.6 2021-10-08
+
+*This is a bugfix update*
+
+* `lh-stats.yml` is now compatible with `LH_RAPID_SYNC`.
+
+## v1.5.5 2021-10-06
+
+*This is a bugfix update*
+
+* Removed doppelganger protection from `lh-validator.yml`, because it does not play well with Teku/Infura
+
+## v1.5.4 2021-10-06
+
+*This is an optional update, that contains new features*
+
+* Support for Prym's new slasher and Lighthouse's slasher
+* Optional `notz` files for Lighthouse and Teku, for use with Amazon Linux 2 or similar
+
+## v1.5.3 2021-10-01
+
+*This is an optional update, that contains new features*
+
+* Support for Lighthouse's new checkpoint sync. Requires LH v2.0.0
+* Support for RocketPool and eth-docker side-by-side, using the consensus client and execution client in eth-docker for both 
+
+## v1.5.2 2021-09-23
+
+*This is an optional update, that contains new features*
+
+* Erigon now uses `prune.r.before` for a PoS-friendly pruned DB. **This is a breaking change for existing Erigon DBs, you'd need to resync**
+* `./ethd config` sets Geth and Erigon Grafana
+* Erigon available as a choice in `./ethd config`
+* New `--dry-run` flag for `auto-prune.sh`
+* New `--keep-targets` flag for `./ethd update`
+
+## v1.5.1 2021-08-23
+
+*This is an optional update, that contains new features*
+
+* Enabled Lighthouse doppelganger protection by default
+
+## v1.5.0 2021-08-19
+
+*This is an optional update, that contains new features*
+
+- **Breaking change** The old `ETH1_*` and `BN_*` variables have been removed. Please make sure your `.env` no longer uses them. `./ethd update` will convert `.env` for you.
+- Teku validator-only setup now works better with load-balanced consensus clients such as Infura
+- Erigon now fully prunes, please see Client Setup documentation as to what that means for consensus client initial sync
+- Initial support for ARM64 setups such as Mac M1, Raspberry Pi4, AWS t4g. This has not been extensively tested, feedback very welcome.
+- `./auto-prune.sh` script that can be run in crontab and will prune Geth when disk space is below 100 GiB free or below 10% free. Requires the `bc` package.
+
+## v1.4.2.4 2021-07-29
+
+*This is a bugfix update*
+
+* Work around a bug in Prysm that kept key import from working
+* Added shared traefik as an advanced option
+
+## v1.4.2.3 2021-07-22
+
+*This is an optional update, that changes behavior*
+
+* `./ethd update` now migrates `.env` first, then builds new client images. This means that people who change build targets
+will need to build again after running an update.
+
+## v1.4.2.2 2021-07-22
+
+*This is a bugfix update*
+
+* Fix `CC_HOST` not persisting on `./ethd update`
+
+## v1.4.2.1 2021-07-22
+
+*This is an optional update, that adds new features*
+
+* Support for the new Erigon `--prune` flag
+* Support for Erigon binary builds
+* **NB** A future release of eth-docker will change the pruning defaults of the Erigon DB, which will require a resync
+from scratch of the DB.
+
+## v1.4.2 2021-07-21
+
+*This is an optional update, that adds new features*
+
+* Support the changed beaconcha.in stats API URL
+
+## v1.4.1.2 2021-07-21
+
+*This is a bugfix update*
+
+* Fixed Teku rapid sync when using grafana
+* Teku now doesn't show initial error messages when using an Infura execution client
+* Created "no timezone" options for teku files, for use with Amazon AMI
+
+## v1.4.1.1 2021-07-21
+
+*This is a bugfix update*
+
+* Fixed Teku validator-only on lowmem machines
+
+## v1.4.1 2021-07-20
+
+*This is an optional update, that contains new features*
+
+* Prysm doppelganger protection enabled by default
+
+## v1.4.0.1 2021-07-13
+
+*This is a bugfix update*
+
+* Fixed fallback execution client for Nimbus
+
+## v1.4.0 2021-07-13
+
+*This is an optional upgrade, that contains new features*
+
+* Added support for Lodestar consensus client
+ 
+## v1.3.3.2 2021-06-16
+
+*This is a bugfix update*
+
+* Fixed ec-traefik.yml
+* Fixed Grafana to use the new consensus name, thanks crymo99!
+* Teku can now run on machines with 8 GiB of RAM, with max heap 4G and soft max heap 2G.
+
+## v1.3.2 2021-06-10
+
+*This is an optional upgrade, that contains new features*
+
+* Added Grafana metrics for Erigon
+* Grafana metrics for standalone Erigon/Geth via `blank-grafana.yml`
+
+## v1.3.0 2021-06-09
+
+*This is an optional upgrade, that contains new features*
+
+* `sudo ./ethd prune-geth` simplifies pruning Geth
+* Separating consensus client and validator client is now supported for Teku, Lighthouse and Prysm. Please see the [Secure Web Proxy](../Usage/ReverseProxy.md) instructions.
+## v1.2.5.2 2021-06-07
+
+*This is a bugfix upgrade*
+
+* `./ethd config` can correctly configure Teku Rapid Sync again
+
+## v1.2.5.1 2021-06-06
+
+*This is a bugfix upgrade*
+
+* `./ethd` help screen works again
+* `sudo ./ethd terminate` command introduced
+
+## v1.2.5 2021-06-05
+
+*This is an optional upgrade, that contains new features*
+
+* Erigon (still in alpha) now syncs a pruned DB
+* `./ethd config` now queries the user for desired Graffiti
+* `sudo ./ethd update` now does a root-safe `git pull` to update eth-docker itself, and uses a different mechanism to redirect error messages for `docker-compose pull`, so it can update components like `node-exporter` with good UX.
+
+## v1.2.4 2021-06-05
+
+*This is a bugfix upgrade*
+
+* `./ethd update` no longer attempts to `docker-compose pull` or `git pull`. In some instances the expected error messages from `docker-compose pull` were not redirected to `/dev/null`, and updating ancillary components while throwing a bevy of error messages is terrible UX.
+
+## v1.2.3 2021-06-04
+
+*This is an optional upgrade, that contains new features*
+
+* `./ethd update` now migrates `.env` variables
+
+## v1.2.2 2021-06-03
+
+*This is an optional upgrade, that contains new features*
+
+* Initial support for erigon via `erigon.yml`. Source build only.
+* Support for sending stats to https://beaconcha.in from Prysm >= 1.3.10 via `prysm-stats.yml`. Source build only.
+* Support for sending stats to https://beaconcha.in from Lighthouse >= 1.4.0 via `lh-stats.yml`. Binary and source builds.
+
+## v1.2.1 2021-05-31
+
+*This is an optional upgrade, that contains new features*
+
+* `./ethd config` now supports setting a fallback execution client
+* Fixed an issue with `--folder` option when using deposit-cli
+
+## v1.2.0 2021-05-28
+
+*This is an optional upgrade, that contains new features*
+
+* This release contains breaking changes to `.env`. Please recreate it from `default.env`, see above.
+* All v1.x releases change the docker images used to run your node. Please be sure to `docker-compose build --pull`
+  before (re)starting your node software.
+
+* Renamed all eth1/beacon references to execution/consensus, to fit with the new naming conventions
+put forth by the Ethereum developers
+* Note this change will cause warning messages, as both `ETH1_` and `EC_` variable names are supported. This
+backwards compatibility will be removed after "Altair", expected August 2021
+
+* Removed OpenEthereum from `./ethd config` as a choice. OpenEthereum will remain a supported execution
+client until Shanghai, to give users time to migrate.
+
+## v1.1.0 2021-05-12
+
+*This is an optional upgrade, that contains new features*
+
+* This release contains breaking changes to `.env`. Please recreate it from `default.env`, see above.
+
+* Validator-only option for Teku and Lighthouse!
+* Teku as the default choice in `default.env`, now that its out-of-the-box RAM use is < 5 GiB
+
+* If you are using any version prior to v1.0.0 released 2021-05-06: PLEASE UPDATE BEFORE October 2021.
+  The script that adjusts permissions for existing setups will be removed again at that point, and
+  any setups that haven't updated by then would have permissions issues when they do update.
+
+## v1.0.0 2021-05-06
+
+*This is an optional upgrade, that contains bugfixes and new features*
+
+With funding from the Ethereum Foundation, we are at v1.0.0! This update makes significant changes to
+the way permissions are handled. While this should improve your experience, please be aware that your `.env` file
+should likely be re-created with a fresh copy of `default.env`, and your specific changes copied in. See above for
+instructions.
+
+* `LOCAL_UID` is no longer being used in `.env`
+* Beacon and Ethereum node containers now run with a "high" user ID, not the user ID of the logged-in user. In
+  order to make this seamless, they use a docker-entrypoint script that changes permissions of existing setups
+  on the fly
+* PLEASE UPDATE BEFORE October 2021. The entrypoint script will be removed again at that point, and
+  any setups that haven't updated by then would have permissions issues when they do update.
+* Prysm now runs on the Prater testnet without the need to manually pass in the genesis state
+* Source builds for Nimbus, Prysm have been fixed; all source builds tested
+* `docker-compose build --pull` is now much faster
+* deposit-cli has been removed from the `CLIENT-base.yml` files. If you do wish to use it, rather than
+  generating keys offline, please add `deposit-cli.yml` to `COMPOSE_FILE`
+* deposit-cli services have been renamed to `deposit-cli-new` and `deposit-cli-existing`
+* The `validator-voluntary-exit` service has been renamed to just `validator-exit`
+* Support for voluntary validator exit when using Teku
+* Preliminary beta configuration script, run `./eth2d.sh` for a quick setup
+
+## v0.3.1 2021-04-22
+
+*This is an optional upgrade, that adds new features*
+
+* Added support for new Teku 21.4.1 features: eth1 failover endpoints, and rapid weak subjectivity sync from infura eth2 project
+
+## v0.3.0 2021-04-21
+
+*This is an optional upgrade, that adds new features*
+
+* Added Traefik reverse proxy for secure access to Grafana and Prysm Web, even eth1 clients. Note this is
+  a breaking change for existing Grafana, Prysm Web and shared/standalone eth1 clients. You will need to
+  add `grafana-insecure.yml`, `prysm-web-insecure.yml`, `eth1-insecure.yml`, depending on service you use,
+  to your `COMPOSE_FILE` inside `.env`. Alternatively and recommended, add `traefik-cf.yml` or `traefik-aws.yml`
+  and start using secure https:// ! Please see [reverse proxy instructions](../Usage/ReverseProxy.md).
+* Added wizard.sh shell script for quick initial setup
+* Added node reporter Grafana dashboard to alert on low CPU, Memory or Disk Space
+
+## v0.2.7 2021-03-10
+
+* Supports Prysm 1.3.3
+* Changed default for Prysm peers to 45
+* `default.env` no longer needs `GETH1_NETWORK` thanks to Geth 1.10.x
+ 
+## v0.2.6.1 2021-02-08
+
+* Nethermind pruning on by default
+* Nimbus ENR IP auto-update on by default
+
+## v0.2.6 2021-01-26
+
+* Added alert manager code. Thanks to @DarrenMa!
+
+## v0.2.5.4 2021-01-21
+
+* Support for new Lighthouse Validator Monitor Grafana Dashboard
+* Better Grafana port handling for use on cloud VPS with ufw
+* OpenEthereum defaults to release tracking with the release of 3.1.1
+
+## v0.2.5.3 2021-01-18
+
+* Changed Nimbus source build to use post-1.0.6 make target and binary names
+* Support for simplified Web UI in Prysm 1.1.0. **NB: prysm-web.yml no longer includes prysm-grafana.yml**
+
+## v0.2.5.2 2021-01-14
+
+* Added support for Nimbus voluntary exit
+* Updated Teku source build to JDK15
+* Changed Teku binary docker to new consensys/teku repository
+* Changed default Nimbus source build target to `stable`
+
+## v0.2.5.1 2021-01-09
+
+* Changed sample-systemd to start services after containerd restart, which helps them survive Ubuntu auto-update
+
+## v0.2.5 2021-01-07
+
+* Support for Nethermind 1.10.x-beta source builds
+
+## v0.2.4.2 2020-12-24
+
+* Support for Lighthouse v1.0.5
+
+## v0.2.4.1 2020-12-16
+
+* Support for Pyrsm fallback eth1 nodes
+
+## v0.2.4 2020-12-07
+
+* Support for new metanull dashboard
+* Initial support for ynager dashboard, eth price not working yet
+
+## v0.2.3.3 2020-12-06
+
+* More time for OpenEthereum to shut down
+* Added documentation on how to restrict access to Grafana when using a VPS
+
+## v0.2.3.2 2020-12-01
+
+* Added max peer values to `default.env`. Make sure to transfer this from `default.env` to your `.env`
+
+## v0.2.3.1 2020-11-30
+
+* Changed Geth shutdown to SIGINT with 2 min timeout so that Geth does not need to resync after
+  `sudo docker-compose down`. In testing Geth took ~50s to shut down on my entry level server.
+
+## v0.2.3 2020-11-29
+
+* First attempt at Geth Grafana metrics. Does not work for eth1-standalone currently
+* Removed Nethermind manual barrier, as it is now part of Nethermind's default mainnet config
+
+## v0.2.2 2020-11-27
+
+* Lighthouse v1.0.1 validator metrics supported
+
+## v0.2.1 2020-11-24
+
+* Support for Besu eth1 client
+* Fixed an issue with Nimbus log file
+* Removed CORS settings for eth1, for now
+* Tightened hosts values for Geth and Besu
+
+## v0.2.0 2020-11-24
+
+* Support for Lighthouse v1.0.0
+* Change default tags for Lighthouse and Prysm to track v1.0.0 release
+
+## v0.1.8.8 2020-11-20
+
+* Initial attempt at Besu integration. While Besu builds, Lighthouse doesn't communicate with it.
+  Strictly for testing.
+
+## v0.1.8.7 2020-11-19
+
+* Integrated community dashboard for lighthouse, teku, and nimbus.
+
+## v0.1.8.6 2020-11-16
+
+* Nethermind added as eth1 option, thanks to adrienlac. Not stable in testing.
+* First attempt at binary option for all but eth2.0-deposit-cli
+
+## v0.1.8.5 2020-11-11
+
+* Added option to run eth1 node exposed to the host on RPC port
+
+## v0.1.8.4 2020-11-08
+
+* Updated grafana image to change all occurrences of `job="beacon"` to `job=beacon_node` in the metanull dashboard.
+* Updated grafana image to rename prysm dashboard titles.
+
+## v0.1.8.3 2020-11-07
+
+* Auto configure Grafana with prometheus datasource.
+* Auto Add `Metanull's Prysm Dashboard JSON` to Grafana
+* Auto Add `Prysm Dashboard JSON` to Grafana
+* Auto Add `Prysm Dashboard JSON for more than 10 validators` to Grafana
+
+## v0.1.8.2 2020-11-06
+
+* Add OpenEthereum eth1 client option
+
+## v0.1.8.1 2020-11-05
+
+* Experimental Prysm slasher - thank you @danb!
+* Fixed Prysm Grafana which got broken when pulling out Prysm Web
+
+## v0.1.8 2020-11-04
+
+* eth2.0-deposit-cli 1.0.0 for Ethereum 2.0 main net
+* First stab at Lighthouse voluntary exit
+* More conservative build targets for Lighthouse, Prysm, Teku, and Geth: Latest release tag instead of `master`
+
+## v0.1.7.5 2020-10-29
+
+* validator-import for Teku now understands Prysm export
+
+## v0.1.7.4 2020-10-29
+
+* Support experimental Prysm Web UI
+
+## v0.1.7.3 2020-10-27
+
+* Prysm change to remove creation of new protection DB, Prysm no longer has this flag
+
+## v0.1.7.2 2020-10-23
+
+* Prysm changes to allow creation of new protection DB and remove experimental web support while it is in flux
+
+## v0.1.7.1 2020-10-16
+
+* Prysm renamed `accounts-v2` to `accounts`, keeping pace with it
+
+## v0.1.7 2020-10-15
+
+* Added "validator-voluntary-exit" to Prysm
+* Default restart policy is now "unless-stopped" and can be changed via `.env`
+* Preliminary work to support Prysm Web UI, not yet functional
+* Changed testnet parameter for Prysm to conform with alpha.29
+* Use `--blst` with Prysm by default for faster sync speed
+* Handles Terms Of Service for Prysm, user is prompted during validator-import, and choice is remembered
+* If you are upgrading this project and you are using Prysm, please run `sudo docker-compose run validator`
+  and accept the terms of use. You can then Ctrl-C that process and start up normally again. This step
+  is not necessary if you are starting from scratch.
+
+## v0.1.6 2020-10-09
+
+* Support for Lighthouse v0.3.0, drop support for v0.2.x
+  * Please note that Lighthouse v0.3.x makes a breaking change to the beacon
+    db. You will need to sync again from scratch, after building the new v0.3.0
+    beacon image. You can force this with 
+    `sudo docker-compose down`, `sudo docker volume rm eth2-docker_lhbeacon-data`
+    (adjust to your directory path if you are not in `eth2-docker`, see
+    `sudo docker volume ls` for a list).
+  * Likewise, the location of the validator keystore has changed. The fastest way
+    to resolve this involves importing the keystore from scratch:
+    `sudo docker volume rm eth2-docker_lhvalidator-data` (as before, adjust for
+    your directory), and then import the keystore(s) again with
+    `sudo docker-compose run validator-import`. Your keystore(s) need to be in
+    `.eth2/validator_keys` inside the project directory for that.
+  * When you have completed the above steps, bring up Lighthouse with
+    `sudo docker-compose up -d eth2` and verify that the beacon started syncing
+    and the validator found its public key(s) by observing logs:<br />
+    `sudo docker-compose logs -f beacon` and `sudo docker-compose logs validator | head -30`,
+    and if you wish to see ongoing validator logs, `sudo docker-compose logs -f validator`.
+  * The beacon will sync from scratch, which will take about half a day. Your
+    validator will be marked offline for that duration.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Clients.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Clients.md
new file mode 100644
index 00000000..ec6af548
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Clients.md
@@ -0,0 +1,34 @@
+---
+id: Clients
+title:  Supported Clients.
+sidebar_label: Clients
+---
+
+This project builds from client teams' official docker images or from official source repositories, pulled
+directly from docker hub or github, respectively. In most cases, binary is the default.
+
+Currently supported consensus clients:
+- [Lodestar](https://github.com/ChainSafe/lodestar)
+- [Nimbus](https://github.com/status-im/nimbus-eth2)
+- [Teku](https://github.com/Consensys/teku)
+- [Grandine](https://github.com/grandinetech/grandine)
+- [Lighthouse](https://github.com/sigp/lighthouse)
+- [Prysm](https://github.com/prysmaticlabs/prysm)
+
+Currently supported execution clients:
+- [Reth](https://github.com/paradigmxyz/reth)
+- [Besu](https://github.com/hyperledger/besu)
+- [Nethermind](https://github.com/NethermindEth/nethermind)
+- [Geth](https://github.com/ethereum/go-ethereum)
+- [Erigon](https://github.com/ledgerwatch/erigon)
+
+> An Ethereum node has one consensus client and one execution client. Eth Docker can be used to split this between two
+machines, but that distributed setup is rare
+
+Currently supported additional options:
+- Sending stats to https://beaconcha.in
+- Prysm Web UI
+- Grafana dashboard
+- slasher - running slasher is optional and requires additional resources
+
+Please see [Prysm Web](../Usage/PrysmWeb.md) for Web UI support on Prysm.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/About/MergePrep.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/MergePrep.md
new file mode 100644
index 00000000..a5501990
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/MergePrep.md
@@ -0,0 +1,31 @@
+---
+id: MergePrep 
+title: Ethereum chain after the merge 
+sidebar_label: Merged Chain
+---
+
+Ethereum has been merged, which changes the way an Ethereum full node is being run
+
+## CL **and** EL both
+
+Both a Consensus Layer and an Execution Layer client are now required.
+
+If you run a Consensus Layer (CL) client such as Lodestar, Nimbus, Teku, Lighthouse, Prysm, then you'll now also need an Execution Layer (EL) client such as Besu, Erigon, Nethermind, Geth.
+
+Conversely, if you run an EL today, you now also need a CL.
+
+This is because Ethereum is using PoS, Proof-of-Stake, consensus and the CL is in complete control of the EL, telling it which fork / chain is real: The "Consensus" in "Consensus Layer". While the EL produces blocks and handles transactions, as it has all along. This happens over something called the Engine API, which we'll get to next.
+
+Check the [Overview](/) for hardware requirements of an Ethereum full node.
+
+## Fee recipient
+
+Since merge, validators receive priority fees and, optionally, MEV. Please see [Rewards](../About/Rewards.md) for details.
+
+## Optional: MEV
+
+MEV is unlocked via mev-boost.
+
+## Engine API connection
+
+The CL connects to the EL on an authenticated RPC or WebSockets engine port (8551 by default), and failover is not supported.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Overview.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Overview.md
new file mode 100644
index 00000000..af8fb892
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Overview.md
@@ -0,0 +1,78 @@
+---
+id: Overview
+slug: /
+title: High Level Overview.
+sidebar_label: Overview
+---
+
+## This project
+
+Eth Docker aims to make running an Ethereum staking full node simpler than setting everything up manually,
+while allowing the user choice when it comes to the exact client mix they wish to run. It's the "easy button" for home stakers,
+with full control for advanced users.
+
+Recommended hardware, whether your own hardware or a VPS, is:
+- 32 GiB of RAM - 16 GiB works but can be challenging depending on client mix
+- 4 CPU cores
+- 4TB ["mainstream" SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038) - TLC and DRAM.
+
+## Node components
+
+An Ethereum staking full node has many moving parts. Here's a high level, conceptual overview.
+
+![Ethereum Node](../../static/img/ethereum-full-node.png)
+
+> The original naming conventions were "eth1" for the execution client, and "beacon"
+> for the consensus client. You will still encounter these names in several places,
+> particularly in the logs of the consensus client.
+> Ethereum PoS (Proof-of-Stake) was also called Ethereum 2.0 at one point, but uses the same ETH token.
+
+## Eth Docker feature highlights
+
+- Supports all FOSS (Free and Open Source Software) Ethereum clients in any combination: Lodestar, Nimbus, Teku,
+Grandine, Lighthouse, Prysm; and Nethermind, Besu, Reth, Erigon, Geth
+- Runs on Linux or macOS, Intel/AMD x64 or ARM or RISC-V CPUs
+- Supports running Ethereum nodes, staking or RPC, on Ethereum and Gnosis Chain; supports running ssv.network DVT
+nodes; supports integration with RocketPool in (reverse) hybrid mode
+- Supports Grafana dashboards and alerting, either locally or Grafana Cloud or even your own remote Mimir/Thanos cluster
+- Uses official client teams' images, does not publish its own images
+- Supports advanced use cases such as exposing interfaces over https with traefik secure web proxy, or source-building clients locally
+
+## Guiding principles:
+
+- Reduce the attack surface of the client as much as feasible.
+- Guide users to good key management as much as possible
+- Create something that makes for a good user experience and guides people new to docker and Linux as much as feasible
+
+## Staking workflow
+
+When setting up an Ethereum staking full node, you'll:
+
+- Configure and run consensus client and  execution client and sync them with testnet or mainnet
+- Generate validator keys, one per 32 Eth you wish to stake. This can and often is done outside of the
+  machine used to run the node, for security reasons.
+- Import validator keys into the validator client, each validator key activates one validator
+- Once the Ethereum execution client and consensus client are fully synced with the chain, deposit Ethereum
+  at the launchpad, 32 ETH per validator key.
+
+Here's what then happens:
+
+- The chain processes the deposit and activates the validators: Your validators start earning rewards
+  and penalties.
+- The consensus client is where it all happens: Block generation, attestations, slashings, with the help
+  of the validator(s) inside the validator client, for signing.
+- A validator earns a reward for every epoch (6.4 minutes) it is online, and a penalty of 3/4 that
+  amount for every epoch it is offline. "Online" means that it sent its scheduled attestation / block
+  proposal. This means you want to be online almost 24/7, but do not have to be afraid of a few hours
+  of downtime, with the exception of periods of non-finality.
+- Greater 2/3 of validators need to be online for the chain to "finalize". If the chain stops finalizing,
+  far harsher penalties for offline validators kick in. Stay online during non-finality. The initial
+  penalties on main net for this "inactivity" during non-finality have been reduced to 1/4th of their eventual
+  values.
+- "Slashing" is a harsh penalty and forced exit for malicious validators; regular penalties could be
+  described as "Leaking" instead. The most likely mistake that gets you slashed is to run a validator key
+  in two separate validator clients simultaneously.
+- If all of the above was so much Gobbledegook, you may want to read the
+[EthStaker knowlege base](https://docs.ethstaker.cc/ethstaker-knowledge-base) and come back to it every time you have
+questions.
+
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Rewards.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Rewards.md
new file mode 100644
index 00000000..a415f3d9
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/Rewards.md
@@ -0,0 +1,30 @@
+---
+id: Rewards
+title: Chain Rewards	 
+sidebar_label: Chain Rewards
+---
+
+Validators that participate in securing the beacon chain and execute "duties" get rewarded for this by new issuance of ETH. In addition, validators receive priority fees paid by users, and optionally MEV, Maximal Extractable Value.
+
+1) Validator rewards
+
+Validators have three duties: Attestations, once every epoch; block production, once every two months or so; sync committees, once every two-and-a-half years or so, on average. Block production and sync committees are randomly assigned, and the time between them therefore varies widely for any one validator. 
+
+They are rewarded for executing those duties by new ETH issuance to the "validator balance". The current APY can be seen on the [official launchpad](https://launchpad.ethereum.org/).
+
+If the validator is down and not executing its duties, it will be penalized at a rate slightly lower than the rewards for the same period of time.
+
+Rewards are withdrawn automatically to the [withdrawal address](https://ethereum.org/en/staking/withdrawals/).
+
+2) Priority fees
+
+Users of Ethereum set a [priority fee](https://ethereum.org/en/developers/docs/gas/#priority-fee) for their transactions. This fee is paid to block proposers and is immediately liquid. In order for that fee to be paid, a `--suggested-fee-recipient` needs to be configured. This is why Eth Docker prompts for an Ethereum address to send priority fees to.
+
+This address could be a hardware wallet, a software wallet, or even a multi-sig contract.
+
+3) MEV
+
+[MEV](https://ethereum.org/en/developers/docs/mev/), or "maximal extractable value", is a controversial topic. Node operators can extract MEV by accepting blocks built by "searchers", via a small side program called ["mev-boost"](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) by Flashbots. In this case, the CL ... Consensus Layer client such as Nimbus, Teku, &c ... will, when asked to procure a block to propose, get blocks from MEV relays via mev-boost and from the EL ... Execution Layer client such as Besu, Geth, &c ... and then choose whichever block from the relay pays best. The EL does not currently communicate its expected payout and would only be chosen when the relay offers no block. For this, the relay has to be trusted to deliver valid blocks.
+
+Rewards from MEV are paid to the same `--suggested-fee-recipient` address that priority fees go to.
+ 
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/About/SecurityAudit.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/SecurityAudit.md
new file mode 100644
index 00000000..9e5d63b0
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/About/SecurityAudit.md
@@ -0,0 +1,33 @@
+---
+id: SecurityAudit
+title: Security Audit
+sidebar_label: Security Audit
+---
+
+# Findings
+
+Sigma Prime conducted a security audit of Eth Docker 2.2.8.4 during March and April 2023, with findings presented on April 30th 2023.
+
+A huge thank-you to both Sigma Prime for the audit, and Ethereum Foundation for funding it.
+
+[Findings as PDF](../../static/pdf/Sigma_Prime_Security_Audit_Findings_2023-05-04_v2.0.pdf)
+
+There are one medium severity and four informational findings. The medium-severity finding is about the entropy used for JWT secret,
+API manager token in Nimbus and Lodestar, Prysm wallet password, and Teku cert password: Entropy comes from `$RANDOM` and is therefore only 16 bits.
+
+# Response
+
+Eth Docker v2.3 addresses these findings. It now uses 64 bits of entropy and SHA-256 hash.
+
+- Secrets entropy
+
+Users that expose the Engine API with `ee-shared.yml` or `ee-traefik.yml` need to make sure that it is firewalled to trusted IPs.
+
+Users that did so before Eth Docker v2.3 may want to, in addition, update with `./ethd update`, stop the stack with `./ethd stop`,
+delete the `jwtsecret` docker volume with `docker volume ls` and `docker volume rm`, and start the stack with `./ethd up`. 
+
+- ED-05 recommends: "Use of clipboard for sensitive strings. Consider giving the user the option of using the clipboard for sensitive
+strings instead of storing the data in a file."
+
+This was not addressed. Engine API JWT secret and keymanager API token need to be present in files for the clients to function. Prysm wallet password is stored
+in a file so the Prysm client can open it. Keymanager API token and Prysm wallet password are printed to stdout if the user requests them.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/AddValidator.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/AddValidator.md
new file mode 100644
index 00000000..18ab07ee
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/AddValidator.md
@@ -0,0 +1,62 @@
+---
+id: AddValidator
+title: Manage validator keys.
+sidebar_label: Manage validator keys
+---
+
+You can use staking-deposit-cli to either recover validator signing keys or add
+additional ones, if you wish to deposit more validators against the same mnemonic.
+
+> The same cautions apply as when creating keys in the first place. You
+> may wish to take these steps on a machine that is disconnected from Internet
+> and will be wiped immediately after creating the keys.
+
+## Recover keys
+
+In order to recover all your validator signing keys, run `./ethd cmd run --rm deposit-cli-existing --uid $(id -u)`
+and provide your mnemonic, then set index to "0" and the number of validators to the number you had created previously
+and are now recreating.
+> Specifying the uid is optional. If this is not done, the generated files will be owned
+> by the user with the user id `1000`
+
+## Create additional keys
+
+In order to add additional validator signing keys, likewise run `./ethd cmd run --rm deposit-cli-existing --execution_address YOURHARDWAREWALLETADDRESS --uid $(id -u)`
+and provide your mnemonic, but this time set the index to the number of validator keys you had created previously,
+for example, `4`. Specify how many *new, additional* validators you want to create. You will receive new `keystore-m` signing keys and a new `deposit_data` JSON.
+> This example assumes that you want to fix withdrawals to an Ethereum address you control, ideally a hardware wallet. You can leave the `--execution_address` parameter out and set a withdrawal address later with your seed phrase (mnemonic).
+
+**Caution**
+
+Please triple-check your work here. You want to be sure the new validator keys are created after
+the existing ones. Launchpad will likely safeguard you against depositing twice, but don't rely
+on it. Verify that the public keys in `deposit_data` are new and you did not deposit for them
+previously.
+
+### Import new keys into existing validator client
+
+Your validator keys, each backed by 32 ETH, "live inside" the validator client. Each key represents one "validator". To add them, simply run `./ethd keys import`, with the new `keystore-m` JSON files in `.eth/validator_keys`. This uses the keymanager API and is done while the client is running.
+
+> **Caution** Please be sure to only import the keys into one validator client. If they are imported to multiple clients, you will slash yourself: A harsh penalty
+> and forced exit of the validator.
+
+## Delete keys and get the slashing protection database
+
+Run `./ethd keys list`, then `./ethd keys delete 0xPUBKEY` with the public key of the key you wish to delete. It will
+be remove from the validator client, and its slashing protection database written to `.eth/validator_keys`
+
+## Set individual fee recipient
+
+Run `./ethd keys list`, then `./ethd keys set-recipient 0xPUBKEY 0xADDRESS` with the public key of the key you wish to set a separate fee recipient for, and the Ethereum address fees should go to.
+
+`./ethd keys get-recipient 0XPUBKEY` shows the recipient
+
+`./ethd keys delete-recipient 0xPUBKEY` deletes the custom recipient, falling back to the default
+
+## Set individual gas limit
+
+Run `./ethd keys list`, then `./ethd keys set-gas 0xPUBKEY AMOUNT` with the public key of the key you wish to set a separate fee recipient for, and the gas limit you wish to set.
+
+`./ethd keys get-gas 0XPUBKEY` shows the gas limit
+
+`./ethd keys delete-gas 0xPUBKEY` deletes the custom gas limit, falling back to the default
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/ChangingWithdrawalCredentials.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/ChangingWithdrawalCredentials.md
new file mode 100644
index 00000000..fd09288b
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/ChangingWithdrawalCredentials.md
@@ -0,0 +1,97 @@
+---
+id: ChangingWithdrawalCredentials
+title: Changing Withdrawal Credentials
+sidebar_label: Changing Withdrawal Credentials
+---
+
+Eth Docker supports using ethdo in an online/offline fashion to prepare withdrawal credential changes files. This follows the [ethdo](https://github.com/wealdtech/ethdo/blob/master/docs/changingwithdrawalcredentials.md) instructions for this process.
+
+**Do NOT under any circumstances enter your mnemonic into a machine that is online or used for daily tasks**
+
+## Check whether your validator has a withdrawal address set
+
+[Ethereum's Staking Launchpad](https://launchpad.ethereum.org/en/withdrawals) will let you see whether your validator has a withdrawal address set. If yes, that is where consensus layer rewards will be swept automatically (every 4-5 days at ~500,000 validators total) and where your funds will be sent when exiting.   
+
+You can use `./ethd keys list` to get a list of your validator public keys that are currently active on your system.
+
+**Only** if you have legacy version 0 / 0x00 style BLS key credentials, continue with the below. If your credentials 
+are already version 1 / 0x01 style withdrawal address credentials, they can only be changed by exiting the validator
+and creating a new one, with a new validator index.
+
+## Offline preparation
+
+On your machine running Eth Docker, run `./ethd keys prepare-address-change`.
+
+Under the hood this will run `ethdo --connection <FIRST_CL_IN_CL_NODE> --allow-insecure-connections validator credentials set --prepare-offline` which creates an `offline-preparation.json` file in `./.eth/ethdo`. This file contains a list of all validators currently on the network and is necessary for the offline machine.
+
+This command will also download `ethdo` itself into this directory.
+
+Copy the contents of this directory, including this `README.md`, `ethdo`, `ethdo-arm64`, the `offline-preparation.json`, and the `create-withdrawal-change.sh` script, to a USB stick (we will call it Data USB).
+
+You should also create a new text file on the Data USB that contains the address you want your validator rewards to go to. This has to be an address you control. Good choices are a hardware wallet where the mnemonic was never online or a contract such as a [multi-signature safe](https://app.safe.global/).
+
+**Do not** set your withdrawal address to an exchange wallet. The funds will not
+be credited, and you will battle support for them.
+
+**Triple-check the withdrawal address you choose! You can only set this once**
+
+If you do not provide the address through a USB stick you will have to type it manually which is prone to human error.
+
+## Make Linux Live USB
+
+Get the [Ubuntu Desktop](https://ubuntu.com/download/desktop) ISO and burn it to a second USB stick (we will call it Live USB) with [Balena Etcher](https://www.balena.io/etcher) or [Rufus](https://rufus.ie/en/).
+
+Plug in the Live USB to your offline computer and turn it on. You will likely need to override the boot target in the UEFI(BIOS) settings. Methods to do this vary by device: Common key interrupts are F2, F8, F12, DEL and Enter. While you are updating the boot target, it would be proper to additionally turn off WIFI, Bluetooth and LAN integrated devices.
+
+Upon saving those settings and exiting the UEFI(BIOS) interface, you will be prompted with a list of options. Choose "Try Ubuntu". Do not install Ubuntu.
+
+After Ubuntu loads, insert the Data USB that holds `ethdo` and the other files from the Offline preparation step.
+
+## Create change credentials file
+
+Verify your internet has been disabled by attempting to visit a website, ping through terminal, or looking in the upper right corner of the desktop.
+
+Open a "Terminal", and cd to the Data USB directory. It will likely be in `/media/ubuntu/USBNAME`. You can use the Files app and right-click the USB, then look at Properties, to see where it is mounted.
+
+Run bash `create-withdrawal-change.sh`.
+
+You will be prompted to specify the withdrawal address you want your funds to be sent to. You should copy that value from the text file.
+
+**Triple-check the withdrawal address you set here! You can only set this once**
+
+You will then be prompted to provide the mnemonic or "seed phrase" of your validator(s). This is needed to sign the change withdrawal request.
+To clarify, this is the mnemonic of the validators' "withdrawal key", which, if you used staking-deposit-cli to make the keys,
+is also the mnemonic of your validator signing keys. It is not the mnemonic of the depositing address, or the withdrawal address.
+
+A file `change-operations.json` will then be created and saved on the Data USB for use with Eth Docker and `ethdo` on your online computer.
+
+Shut down Ubuntu which will make your PC "forget" anything it knew about your mnemonic during this process.
+
+At this point your Live USB will no longer be needed.
+
+## Broadcast changes to the chain
+
+### Using the beacocha.in explorer
+
+Did I mention to **triple-check the withdrawal address you have set? You can only set this once!**
+
+Go to [https://beaconcha.in/tools/broadcast](https://beaconcha.in/tools/broadcast) and drag-drop the change-operations.json file in. It will be broadcast to the chain and drag-drop the `change-operations.json` file in. It will be broadcast to the chain.
+
+### Using your own Eth Docker CL
+
+Insert the Data USB to your online computer where Eth Docker is running.
+
+Copy the `change-operations.json` from the Data USB to `./.eth/ethdo` on your Eth Docker node.
+
+Run `./ethd keys send-address-change`. You will have one more chance to verify your withdrawal address.
+
+Did I mention to t**riple-check the withdrawal address you have set? You can only set this once!**
+
+If a Shanghai/Capella fork has been announced on your chain, the changes will be loaded into the consensus layer client for broadcast. If Shanghai/Capella is live, they will be broadcasted. Inclusion should take ~3 days after the hardfork date if everyone piles in at once or should be almost immediate if you have waited.
+
+## Check whether your validator has a withdrawal address set
+
+Obsessively refresh [Metrika](https://app.metrika.co/ethereum/dashboard/withdrawals-overview) to see whether your validator now has a withdrawal address set. If yes, that is where consensus layer rewards will be swept automatically every 4-5 days at ~500,000 validators total.
+
+You can use `./ethd keys list` to get a list of your validator public keys that are currently active on your system.
+
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Cloud.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Cloud.md
new file mode 100644
index 00000000..a4dcb085
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Cloud.md
@@ -0,0 +1,154 @@
+---
+id: Cloud
+title:  Securing a cloud VPS.
+sidebar_label: Cloud Security
+---
+
+For the most part, nothing special needs to be done to run Eth Docker on a VPS. However, budget VPS providers do not
+filter the traffic that can reach the machine: This is definitely not desirable for unsecured ports like Grafana
+or execution client, if the shared option is being used. All that should be reachable are the P2P ports.
+
+The arguably best way to secure Grafana, Web UI and execution client ports is via encryption. For this, please see the [secure proxy](../Usage/ReverseProxy.md)
+instructions.
+
+If you prefer to keep the ports unencrypted and wish to secure them via ufw, please read on.
+## Securing Grafana and execution client via ufw
+
+While Docker automatically opens the Linux firewall for ports it "maps" to the host, it also
+allows rules to be placed in front of that, via the `DOCKER-USER` chain.
+
+The following idea uses that chain and integrates ufw with it, so that simple ufw rules can
+be used to secure Grafana.
+
+### 1) Edit after.rules:
+
+`sudo nano /etc/ufw/after.rules` and add to the end of the file, *after* the existing `COMMIT`:
+
+```
+*filter
+:ufw-user-input - [0:0]
+:DOCKER-USER - [0:0]
+
+# ufw in front of docker while allowing all inter-container traffic
+
+-A DOCKER-USER -j RETURN -s 172.17.0.0/16
+-A DOCKER-USER -j RETURN -s 172.18.0.0/16
+-A DOCKER-USER -j RETURN -s 172.19.0.0/16
+-A DOCKER-USER -j RETURN -s 172.20.0.0/14
+-A DOCKER-USER -j RETURN -s 172.24.0.0/14
+-A DOCKER-USER -j RETURN -s 172.28.0.0/14
+-A DOCKER-USER -j RETURN -s 192.168.0.0/16
+
+-A DOCKER-USER -j ufw-user-input
+-A DOCKER-USER -j RETURN
+
+COMMIT
+```
+
+Note this deliberately keeps ufw rules from influencing any traffic sourced from the standard Docker private IP ranges.
+This may *not* be what you need, in which case just remove those seven lines, and be sure to allow needed
+container traffic through explicit ufw rules, if you are blocking a port.
+
+### 2) Edit before.init
+
+`sudo nano /etc/ufw/before.init` and change `stop)` to read:
+
+```
+stop)
+    # typically required
+    iptables -F DOCKER-USER || true
+    iptables -A DOCKER-USER -j RETURN || true
+    iptables -X ufw-user-input || true
+    ;;
+```
+
+Then, make it executable: `sudo chmod 750 /etc/ufw/before.init`
+
+Dropping `ufw-user-input` through `before.init` is a required step. Without it, ufw cannot be reloaded, it would display an error message
+stating "ERROR: Could not load logging rules".
+
+### 3) Reload ufw
+
+`sudo ufw reload`
+
+### Example: Grafana on port 3000
+
+Reference [common ufw rules and commands](https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands)
+to help in creating ufw rules.
+
+Say I have Grafana enabled on port 3000 and no reverse proxy. I'd like to keep it reachable via [SSH tunnel](https://www.howtogeek.com/168145/how-to-use-ssh-tunneling/)
+while dropping all other connections.
+
+First, verify that Grafana is running and port 3000 is open to world using something like https://www.yougetsignal.com/tools/open-ports/
+
+Next, create ufw rules to allow access from `localhost` and drop access from anywhere else:
+
+- `sudo ufw allow from 127.0.0.1 to any port 3000`
+- `sudo ufw deny 3000`
+
+Check again on "yougetsignal" or the like that port 3000 is now closed.
+
+Connect to your node with ssh tunneling, e.g. `ssh -L3000:node-IP:3000 user@node-IP` and browse to `http://127.0.0.1:3000` on the client
+you started the SSH session *from*. You expect to be able to reach the Grafana dashboard.
+
+### Example: Prysm Web UI on port 7500
+
+Reference [common ufw rules and commands](https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands)
+to help in creating ufw rules.
+
+Say I have the Prysm Web UI enabled on port 7500 and no reverse proxy. I'd like to keep it reachable via [SSH tunnel](https://www.howtogeek.com/168145/how-to-use-ssh-tunneling/)
+while dropping all other connections.
+
+First, verify that Prysm Web UI is running and port 7500 is open to world using something like [you get signal](https://www.yougetsignal.com/tools/open-ports/)
+
+Next, create ufw rules to allow access from `localhost` and drop access from anywhere else:
+
+- `sudo ufw allow from 127.0.0.1 to any port 7500`
+- `sudo ufw deny 7500`
+
+Check again on [you get signal](https://www.yougetsignal.com/tools/open-ports/) or the like that port 7500 is now closed.
+
+Connect to your node with ssh tunneling, e.g. `ssh -L7500:node-IP:7500 user@node-IP` and browse to `http://127.0.0.1:7500` on the client
+you started the SSH session *from*. You expect to be able to reach the Prysm Web UI.
+
+### Example: Shared or standalone execution client on port 8545
+
+It can be useful to have a single execution client service multiple consensus clients, for example when testing, or running a solo staking docker-compose stack as well as a pool docker-compose stack.
+
+To allow Docker traffic to the execution client while dropping all other traffic:
+- `sudo ufw allow from 172.16.0.0/12 to any port 8545`
+- `sudo ufw allow from 192.168.0.0/16 to any port 8545`
+- `sudo ufw allow from 10.0.0.0/8 to any port 8545`
+- `sudo ufw deny 8545`
+- `sudo ufw allow from 172.16.0.0/12 to any port 8546`
+- `sudo ufw allow from 192.168.0.0/16 to any port 8546`
+- `sudo ufw allow from 10.0.0.0/8 to any port 8546`
+- `sudo ufw deny 8546`
+
+> With ISP traffic caps, it could be quite attractive to run the execution client in a small VPS, and reference it from a consensus client somewhere
+> else. This requires a [secure proxy](../Usage/ReverseProxy.md).
+
+### Allowing Docker traffic to the host IP
+
+Ports mapped to host by Docker are reachable by default without the need for ufw rules. There is one exeption:
+If a Docker container on the host tries to reach a port mapped to host by the host IP, this will fail by default.
+
+Example: I am running a Docker container on a host with IP `1.2.3.4`, port `26000` is mapped to host, and the container
+tries to reach its own port as `1.2.3.4:26000` instead of `localhost:26000`. This will fail.
+
+This is a highly unusual configuration, as a Docker bridge network would typically be used instead of the host IP.
+If you do need to reach the host IP from a Docker container, however, a ufw rule like this would do it:
+
+```
+sudo ufw allow from 172.16.0.0/12 to any port <PORT>
+sudo ufw allow from 192.168.0.0/16 to any port <PORT>
+````
+
+The rules above are a little overly broad for simplicity, to cover all default Docker subnets. You can restrict this
+to the actual defaults by adding more specific rules. For the Docker default subnets, see the section about
+`after.rules`.
+
+## Acknowledgements
+
+The ufw integration is a slightly tweaked version of https://github.com/chaifeng/ufw-docker by way 
+of https://p1ngouin.com/posts/how-to-manage-iptables-rules-with-ufw-and-docker
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Exit.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Exit.md
new file mode 100644
index 00000000..dfe0a8bb
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Exit.md
@@ -0,0 +1,114 @@
+---
+id: Exit
+title:  Voluntary validator exit
+sidebar_label: Voluntary exit
+---
+
+Ethereum PoS has a concept of "voluntary validator exit", which will remove the
+validator from attesting duties. Staked ETH will be withdrawn automatically
+to the withdrawal address, as long as one has been set.
+
+**Do not** set your withdrawal address to an exchange wallet. The funds will not
+be credited, and you will battle support for them.
+
+Exiting a validator requires a fully synced consensus client. Checkpoint sync,
+configured with `RAPID_SYNC_URL` in `.env`, can sync one in minutes.
+
+# Exit using keymanager API
+
+- Get a list of your keys with `./ethd keys list`
+- Sign an exit message with `./ethd keys sign-exit 0xpubkey`
+
+This signed message is valid for the life of your validator; you do not have to use it right away
+(you could, for example, keep it for your heirs). 
+
+As and when you want to submit a voluntary exit you can:
+- Submit the JSON file to [beaconcha.in](https://beaconcha.in/tools/broadcast)  
+OR
+- Use `./ethd keys send-exit` to send all created exits through your own consensus layer client
+
+You can track the status of your voluntary exit request at `https://beaconcha.in/validator/<validator-id>`. 
+There are three steps:
+- Your validator becomes 'Exited' (5-6 epochs (~35 minutes), assuming no [exit queue](https://www.validatorqueue.com/))
+- Your validator exit becomes 'Withdrawable' (256 epochs (~27 hours))
+- Your 32 Eth is returned to your withdrawal address (currently a maximum of just under a week, see the 'Withdrawals' 
+tab at `https://beaconcha.in/validator/<validator-id>` for the next scheduled withdraw for your validator)
+
+
+# Avoid penalties
+
+Note you will need to continue running your validator until the exit has been processed by the chain, if you wish to
+avoid incurring offline penalties. You can check the status of your validator with tools such as
+[beaconcha.in](https://beaconcha.in).
+
+# Exit using keystore-m and ethdo
+
+- Place all keys to be exited into `.eth/validator-keys`
+- Run `./ethd keys sign-exit from-keystore`, optionally with `--offline` if you have an `offline-preparation.json` for
+ethdo
+
+This will sign exit messages with ethdo, which you can then store for your heirs or submit.
+
+This method has the advantage of not requiring the keys to be loaded into a validator client first, and is ideal when
+the validators are being run by a 3rd-party service.
+
+This works when Eth Docker is not the primary way to run the node. For example, for a systemd setup, you could
+`nano .env`, set `COMPOSE_FILE=ethdo.yml`, and set `CL_NODE=http://HOSTIP:5052`, adjusting `HOSTIP` to the IP address
+of your node and `5052` to the port REST is available on. Note that for this to work, the REST port needs to be
+reachable by host IP, *not* just by `localhost`. When in doubt, the `--offline` method will always work.
+
+# Legacy exit using client-specific tools
+
+## Teku
+
+Teku will exit all validators that have been imported to it. Run
+`./ethd cmd run --rm validator-exit` and follow the prompts.
+
+## Prysm
+
+To exit, run `./ethd cmd run --rm validator-exit` and follow the
+prompts.
+
+## Lighthouse
+
+The exit procedure for Lighthouse requires a copy of the keystore JSON files.
+
+- Copy the `keystore-m` JSON files into `.eth/validator_keys/` in this project directory.
+- Run `./ethd cmd run --rm validator-exit /keys/<name-of-keystore-file>`, once for each keystore (validator) you wish to exit.
+- Follow prompts.
+
+> The directory `.eth/validator_keys` is passed through to docker as `/keys`. Lighthouse
+> expects you to explicitly name the `keystore-m` file for which you wish to process an exit. Because this can
+> be confusing, here's an example:
+```
+yorick@ethlinux:~/eth-pyrmont$ ls .eth/validator_keys/
+deposit_data-1605672506.json  keystore-m_12381_3600_0_0_0-1605672506.json
+yorick@ethlinux:~/eth-pyrmont$ ./ethd cmd run --rm validator-exit /keys/keystore-m_12381_3600_0_0_0-1605672506.json
+Starting eth-pyrmont_consensus_1 ... done
+Running account manager for pyrmont testnet
+validator-dir path: "/keys" 
+Enter the keystore password for validator in "/keys/keystore-m_12381_3600_0_0_0-1605672506.json"  
+```
+
+## Nimbus
+
+The exit procedure for Nimbus requires a copy of the keystore JSON files.
+
+- Copy the `keystore-m` JSON files into `.eth/validator_keys/` in this project directory.
+- Run `./ethd cmd run --rm validator-exit /keys/<name-of-keystore-file>`, once for each keystore (validator) you wish to exit.
+- Follow prompts.
+
+> The directory `.eth/validator_keys` is passed through to docker as `/keys`. Nimbus
+> expects you to explicitly name the `keystore-m` file for which you wish to process an exit. Because this can
+> be confusing, here's an example:
+```
+ubuntu@eth-testing:~/eth-docker-devel$ ./ethd cmd run --rm validator-exit /keys/keystore-m_12381_3600_0_0_0-1681561909.json
+Please enter the password for decrypting '/keys/keystore-m_12381_3600_0_0_0-1681561909.json'
+Password:
+```
+
+## Lodestar
+
+To exit a specific validator, run `./ethd cmd run --rm validator-exit --pubkeys <0xPUBKEY>`.  
+Multiple validators can be exited by providing a comma-separated list of public keys to `pubkeys`.  
+If no `pubkeys` are provided, it will exit all validators that have been imported.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/GethPrune.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/GethPrune.md
new file mode 100644
index 00000000..96a4ee4a
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/GethPrune.md
@@ -0,0 +1,27 @@
+---
+id: GethPrune
+title: Execution client prune
+sidebar_label: Prune execution client
+---
+
+### Automatic Nethermind prune
+
+By default, Nethermind will prune when free disk space falls below 350 GiB on mainnet, or 50 GiB on testnet. If you
+want to disable that, `nano .env` and change `AUTOPRUNE_NM` to `false`.
+
+### Continuous Besu prune
+
+Besu continuously prunes with BONSAI, and from 24.1.0 on also prunes its trie-logs. A long-running Besu may benefit
+from a manual trie-log prune, once.
+
+### Continuous Geth prune
+
+Geth continuously prunes if synced with PBSS. If you are using an old hash-synced Geth, run `./ethd resync-execution`
+to use PBSS. This will cause downtime while Geth syncs, which can take 6-12 hours.
+
+### Manual Nethermind or Besu prune
+
+Run `./ethd prune-nethermind` if using Nethermind. It will check prerequisites, online prune Nethermind, and restart it.
+
+Run `./ethd prune-besu` if using a long-running Besu. It will check prerequisites, offline prune Besu trie-logs, and
+restart it.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/HelpfulWebsites.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/HelpfulWebsites.md
new file mode 100644
index 00000000..e0727f23
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/HelpfulWebsites.md
@@ -0,0 +1,28 @@
+---
+id: HelpfulWebsites
+title: Helpful Websites
+sidebar_label: Helpful Websites
+---
+
+## EthStaker
+[https://ethstaker.cc/](https://ethstaker.cc/) - EthStaker website
+
+[https://ethstaker.cc/support](https://ethstaker.cc/support) - Social media links
+
+## Educational
+
+[https://launchpad.ethereum.org/en/](https://launchpad.ethereum.org/en/) - Official Staking Launchpad website
+
+[https://ethereum.org/en/staking/](https://ethereum.org/en/staking/) - Broad overview of ETH staking
+
+[https://ethereum.org/en/run-a-node/](https://ethereum.org/en/run-a-node/) - Running a validator on Ethereum requires running a node first.
+
+## Monitoring
+
+[https://www.validatorqueue.com/](https://www.validatorqueue.com/) - The Ethereum validator entry and exit queues have varying waiting times depending on the state of the network. The entry queue has historically reached as long as 45 days.
+
+[https://beaconcha.in/](https://beaconcha.in/) - Track the stats of your validator on the Beacon Chain, including waiting times, deposits and withdrawals, and overall performance. If you create an account, you can also monitor your validator to receive email notifications for any potential problems.
+
+[https://launchpad.ethereum.org/en/withdrawals](https://launchpad.ethereum.org/en/withdrawals) - Check your validator's withdrawal credentials
+
+
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Moving.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Moving.md
new file mode 100644
index 00000000..48952c07
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Moving.md
@@ -0,0 +1,87 @@
+---
+id: Moving
+title:  Moving a validator.
+sidebar_label: Moving
+---
+
+When you wish to move a validator, the most important part is that you do not
+cause yourself to get slashed. "Slashing" is a large penalty and a forced
+exit of the validator.
+
+The first slashings on mainnet occurred because someone was running a validator in
+two places at once. **Don't be that person.**
+
+Read the [Ethereum PoS primer](https://ethos.dev/beacon-chain/) to understand how
+a validator can get slashed. The most common way is to simply run two copies of it
+at once.
+
+## When to move
+
+When you absolutely have to. You incur an offline penalty of 3/4 of the reward
+you could have made in the same time. This means it is often better to take a day
+or several of downtime and work on getting the node back online, than risk
+slashing while moving validator keys.
+
+That said, if you are down during non-finality, or are abandoning a node to start
+a new one elsewhere, you may need to know how to move your key(s) safely.
+
+## What you'll need
+
+- [ ] Your signing keys in keystore-m JSON format, and the password for them
+>  If you do not have these any more, you can recreate them with the `existing-mnemonic`
+>  workflow of deposit-cli, `./ethd cmd run --rm deposit-cli-existing` in
+>  this project, or offline to be very secure.
+- [ ] Ideally, an export of the slashing protection DB. If you are using Eth Docker, `./ethd keys delete` will export the slashing protection database.
+- [ ] A checklist, and diligence
+
+## Checklist
+
+Are you positive you need to move? Can you take a day or a couple of downtime and bring
+your old node back up? If so, do that.
+
+Assuming you must move the validator keys to a new client, here are the steps.
+
+### Bring down old client
+
+First, you'll want to bring down the old client and make sure it can't come back up.
+
+In the directory of the old client:
+
+- [ ] `./ethd keys list`
+- [ ] `./ethd keys delete all` so you get the slashing protection database
+- [ ] `./ethd terminate`
+
+### Verify
+
+Verify that you removed the right client:
+
+- [ ] `./ethd cmd run --rm validator` - confirm that it complains it cannot find its keys. If it still
+  finds validator keys, do not proceed until you fixed that and it doesn't.
+  > For Nimbus and Teku, the command is `./ethd cmd run --rm consensus` instead
+- [ ] Look at https://beaconcha.in/ and verify that the validator(s) you just removed are now
+  missing an attestation. Take a note of the epoch the last successful attestation was in.
+- [ ] Verify that both machines are synchronized to time and are using NTP.
+- [ ] Allow 15 minutes to go by and verify that the last successful attestation's epoch is now
+  finalized. Only then take the next step.
+
+### Import keys into new client
+
+- [ ] SCP (or USB sneaker-net) the keys to `.eth/validator_keys` in the project directory
+- [ ] Ideally, also copy `slashing_protection*.json` to `.eth/validator_keys`
+- [ ] Verify **once more** that all your validator(s) have been down long
+  enough to miss an attestion
+- [ ] Verify **once more** that trying to start the validator on the old client
+  has it complaining it can't find keys, so that there is **no way** it
+  could run in two places.
+- [ ] If you are absolutely positively sure that the old validator client cannot
+  start attesting again and 15 minutes have passed / **all** validators'
+  last successful attestation is in a finalized epoch, then and only then:
+- [ ] Start the new client with `./ethd up`
+- [ ] Run `./ethd keys import` and import the keys
+
+
+### Variant: DR consensus client
+
+You can keep a client fully synchronized without keys. No keys "ready
+to be imported" on the node, and no keys imported. That way, if and
+when you do need to move, you do not need to wait for initial sync.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Recommendations.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Recommendations.md
new file mode 100644
index 00000000..2c71d928
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Recommendations.md
@@ -0,0 +1,105 @@
+---
+id: Recommendations
+title:  Recommendations.
+sidebar_label: Recommendations
+---
+
+Some recommendations on security of the host, general operation,
+and key security.
+
+## Operation
+
+**Do not run two validator clients with the same validator keys imported at the same time**<br />
+You'd get yourself slashed, and no-one wants that. Protecting you from this
+is a work in progress. Choose one client, and one client only, and run that.
+
+## Host Security
+
+The [bare metal installation guide](https://someresat.medium.com/guide-to-staking-on-ethereum-ubuntu-nimbus-31f56657ea8f)
+by /u/SomerEsat has excellent notes on Linux host security. Running `ntpd`
+is highly recommended, time matters to validators. Note the ports
+you will need to open in `ufw` depend on the client you choose.
+
+## Firewalling
+
+execution client: 30303 tcp/udp, forwarded to your server<br />
+consensus client: 9000 tcp/udp, forwarded to your server<br />
+grafana/web UI: 443 tcp, forwarded to your server, assuming you are using the reverse proxy.<br />
+
+> The grafana port is insecure http:// if no reverse proxy is in use,
+> and should then only be access locally.
+> An [SSH tunnel](https://www.howtogeek.com/168145/how-to-use-ssh-tunneling/)
+> is also a great option if you do not want to use the reverse proxy.
+
+## Before depositing
+
+You likely want to wait to deposit your ETH until you can see in the logs
+that the execution client (e.g. geth) is synchronized and the consensus client
+is fully synchronized. This takes hours on testnet and could take days on mainnet.
+
+If you deposit before your client stack is fully synchronized and running,
+you risk getting penalized for being offline. The offline penalty during
+the first 5 months of mainnet will be roughly 0.13% of your deposit per
+week.
+
+## Wallet and key security
+
+The security of the wallet mnemonic you create is **critical**. If it is compromised, you will lose
+your balance. Please make sure you understand Ethereum staking before you use this project.
+
+When you create the deposit and keystore files, write down your wallet mnemonic and
+choose a cryptographically strong password for your keystores. Something long
+and not used anywhere else, ideally randomized by a generator.
+
+The directory `.eth/validator_keys` will contain the `deposit_data-TIMESTAMP.json` and `keystore-m_ID.json`
+files created by staking-deposit-cli.
+
+Use `deposit_data-TIMESTAMP.json` for your initial deposit. After that, it can be disposed of.
+
+Use `keystore-m_ID.json` files to import your validator secret keys into the validator client
+instance of the client you are running. These files need to be secured when you are done
+with the initial import.
+
+### Validator Key Security
+
+The `keystore-m_ID.json` files have to be stored securely outside of this server. Offline
+is best, on media that cannot be remotely compromised. Keep the password(s) for
+these files secure as well, for example in a local (not cloud-connected) password vault
+on a PC that is not on the network, or at the very least not used for online access.
+
+Once you have the keystore files secure and they've been imported to the validator client container
+on your server, you should delete them from the `.eth` directory.
+
+These files will be needed in case you need to restore your validator(s).
+
+**Caution**<br />
+An attacker with access to these files could slash your validator(s) or threaten
+to slash your validator(s).
+
+For more on validator key security, read this article: https://www.attestant.io/posts/protecting-validator-keys/
+
+### Withdrawal Key Security
+
+**Critical**<br />
+When you ran staking-deposit-cli, a 24-word mnemonic was created. This mnemonic
+is used for Ethereum validator exits and withdrawals. It must be securely kept offline.
+Without this mnemonic, unless you set a withdrawal address via `--execution_address`, there is **no** way to withdraw your funds.
+
+Precise methods are beyond this README, but consider something as simple as
+a sheet of paper kept in a fireproof envelope in a safe, or one of the [steel
+mnemonic safeguards](https://jlopp.github.io/metal-bitcoin-storage-reviews/) that are available.
+
+Test your mnemonic **before** you deposit, so you know that you will be able
+to withdraw funds in future.
+
+An attacker with access to your mnemonic can drain your funds, if no withdrawal address was set during key generation. If one
+was set, they can't get the validator funds, but can cause a "slashing", a penalty of around 1.1 ETH and forced exit of the validator.
+
+For more on withdrawal key security, read this article: https://www.attestant.io/posts/protecting-withdrawal-keys/
+
+> Testing your mnemonic can be as simple as typing it into deposit-cli
+> with `existing-mnemonic`, then comparing the public key(s) of the resulting
+> keystore-m signing key files to the public keys you know your validator(s)
+> to have. The safest way to do this is offline, on a machine that will
+> never be connected to Internet and will be wiped after use.
+
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Rocketpool.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Rocketpool.md
new file mode 100644
index 00000000..84fc4bfd
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Rocketpool.md
@@ -0,0 +1,107 @@
+---
+id: Rocketpool
+title: Integration with Rocketpool.
+sidebar_label: Integration with Rocketpool
+---
+
+RocketPool node and Eth Docker solo staking, it's like peanut butter and jelly. Both use docker, and they integrate seamlessly.
+
+I'll be showing two configurations: Chain databases in Rocketpool, and chain databases in Eth Docker.
+
+This should work for any client that Rocketpool supports.
+
+## Configuration A: Chain databases in RocketPool
+
+For this example, the consensus client (beacon/eth2) and execution client (eth1) will run in RocketPool, and Eth Docker will run just a validator client, but not "consensus" or "execution" containers.
+
+### Configure RocketPool
+
+If you are not running RocketPool already, install it [following their instructions](https://docs.rocketpool.net/guides/node/docker.html). When you get to the step where you configure RocketPool:
+
+`rocketpool service config` and choose Locally Managed, any local Execution Client (Geth, Erigon, etc) and any Consensus Client.
+
+Run `rocketpool service start`, and everything should come up. 
+
+You can continue following the Rocketpool instructions at this point.
+
+### Configure Eth Docker
+
+If you are not running Eth Docker already, grab it with `git clone https://github.com/eth-educators/eth-docker.git && cd eth-docker`.
+
+#### With remote Prysm
+
+Configure Eth Docker with `./ethd config`. Make sure to choose the same Ethereum PoS network as RocketPool, and a "Validator client only" to match the Consensus client in RocketPool. Choose "eth2:5053" (note no "http://") as your "remote consensus client" if your solo validator client is Prysm, and "http://eth2:5052" as your "remote consensus client" if your solo validator client is anything else. Doppelganger protection works for Prysm and Nimbus VCs towards a Prysm CL. Any other VC requires Doppelganger to be off.
+
+#### For any other remote CL
+
+Configure Eth Docker with `./ethd config`. Make sure to choose the same Ethereum PoS network as RocketPool, and a "Validator client only" to match the Consensus client in RocketPool. Choose "http://eth2:5052" as your "remote consensus client".
+
+> Lighthouse and Teku are mutually compatible, they can be mixed and matched
+
+#### Start and cleanup
+
+If you had previously already imported keys to Eth Docker, restart Eth Docker with `./ethd restart`.
+
+Optional cleanup: If you had chain databases in Eth Docker previously, do a `docker volume ls` and then `docker volume rm` the consensus/beacon and eth1/ec volumes, e.g. `eth-docker_geth-eth1-data` and `eth-docker_lhbeacon-data`.
+
+### Import solo staking keys
+
+If you haven't already imported validator keys to Eth Docker, do so now. You will need the `keystore-m` files and their
+password.
+
+- Copy `keystore-m` files to `.eth/validator_keys` in the `eth-docker` directory
+- From the `eth-docker` directory, start Eth Docker: `./ethd up`
+- Import keys and follow prompts: `./ethd keys import`
+- Verify keys came in: `./ethd keys list`
+
+### Check logs
+
+You expect `./ethd logs -f validator` to show a successful connection. 
+
+`rocketpool service logs validator` should show the validator connecting to its own consensus client.
+`docker ps` should show `rocketpool_eth1` and `rocketpool_eth2` containers, but no `consensus` or `execution` containers for Eth Docker.
+
+## Configuration B: Chain databases in Eth Docker
+
+For this example, the consensus client (beacon/eth2) and execution client (eth1) will run in Eth Docker, as well as the solo staking validator client, and RocketPool will run its own validator client as well as its node container, but not "eth1" or "eth2" containers.
+
+### Configure RocketPool
+
+If you are not running RocketPool already, install it [following their instructions](https://docs.rocketpool.net/guides/node/docker.html). When you get to the step where you configure RocketPool:
+
+- `rocketpool service config` and choose `Externally Managed` for the Execution Client, and as your http URL use `http://execution:8545` and as the websocket URL use `ws://execution:8546`. Choose `None` for your fallback client. Choose `Externally Managed` for the Consensus Client, and choose the client you want to run in Eth Docker. As the http URL use `http://consensus:5052`. If you are using Prysm, use `consensus:4000` instead.
+
+Set up Eth Docker next before following the rest of the Rocketpool instructions.
+
+### Configure Eth Docker
+
+If you are not running Eth Docker already, grab it with `git clone https://github.com/eth-educators/eth-docker.git && cd eth-docker`, and configure it with `./ethd config`. Choose an Ethereum node deployment. Make sure to choose the same Ethereum PoS network and consensus layer client as you chose in RocketPool.
+
+Of note, the Prysm validator client in RocketPool only works with the Prysm consensus layer client in Eth Docker. Other clients can be mixed and matched to an extent, e.g. a Lighthouse validator client in RocketPool to a Teku consensus layer client in Eth Docker.
+
+Connect Eth Docker to RocketPool's docker network.
+
+- `nano .env` and add `:ext-network.yml` to `COMPOSE_FILE`
+- `nano ext-network.yml` and change the line that reads `name: traefik_default` to `name: rocketpool_net`
+- `./ethd start` or, if you already have Eth Docker running, `./ethd update` followed by `./ethd up`
+- `rocketpool service start` and Rocketpool should come up
+
+You can continue following the Rocketpool instructions at this point.
+
+### Import solo staking keys
+
+If you haven't already imported validator keys to Eth Docker, do so now. You will need the `keystore-m` files and their
+password.
+
+- Copy `keystore-m` files to `.eth/validator_keys` in the eth-docker directory
+- From the eth-docker directory, start Eth Docker: `./ethd up`
+- Import keys and follow prompts: `./ethd keys import`
+- Verify keys came in: `./ethd keys list`
+
+### Check logs
+
+`./ethd logs -f consensus` should show it starting up, ditto `./ethd logs -f execution`, and after consensus is up, you expect
+`./ethd logs -f validator` to show a successful connection. Solo staking is (still) working.
+
+`rocketpool service logs validator` should show the validator connecting to your consensus client.
+`docker ps` should show no `rocketpool_eth1` or `rocketpool_eth2` containers.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/SSV.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/SSV.md
new file mode 100644
index 00000000..f9f10ce1
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/SSV.md
@@ -0,0 +1,78 @@
+---
+id: SSV
+title: Run an SSV node.
+sidebar_label: Run an SSV node
+---
+
+Eth Docker supports running an SSV node, together with a consensus client and execution client of choice.
+
+## Setup Prerequisites
+### Get Eth Docker
+- Clone this tool
+  - `git clone https://github.com/eth-educators/eth-docker.git ssv-node && cd ssv-node`
+
+### On Linux
+- Install docker, unless you already have it
+  - Run `./ethd install`
+
+### On MacOS
+- Install [Docker Desktop](https://www.docker.com/products/docker-desktop) and allocate 16 GiB of RAM and around 3TB
+of storage to it
+- Install pre-requisites via homebrew
+  - `brew install coreutils newt bash`
+
+## Setup an SSV Node
+
+Run `./ethd config` and choose SSV Node in the first dialog:
+
+![eth-docker deployment type dialog](../../static/img/ssv-node.png)
+
+The next question asks if the operator should be participating in DKG ceremonies. For more information, visit [SSV official documentation on the subject](https://docs.ssv.network/developers/tools/ssv-dkg-client).
+
+![eth-docker deployment type dialog](../../static/img/dkg.png)
+
+Follow the instructions and finally, choose your preferred consensus and execution clients, and
+rapid sync for the consensus client. Choose Grafana for visibility.
+
+The config script will create a config file, password and encrypted node key in `./ssv-config`.
+
+Start everything with `./ethd up`.
+
+You can watch logs with `./ethd logs -f ssv-node`, which will also give you the public key of your node.
+
+Back up the contents of `./ssv-config`! If these are lost, you cannot recreate your node installation as registered
+with ssv.network.
+
+>Right after startup, the ssv-node will fail because it cannot get to `http://consensus:5052`. This is normal! It will
+resolve once the consensus client has started and is listening on the REST API port. You can use
+`./ethd logs -f consensus` to see it do that.
+
+## Mapping ports
+
+By default, the SSV node uses ports TCP 13,001 and UDP 12,001 for its P2P network with other nodes. These ports need to
+be reachable from the Internet.
+
+If you need to change the ports, you can do so by changing the `SSV_P2P_PORT` and `SSV_P2P_PORT_UDP` variables in
+`.env`, and changing the corresponding values in `ssv-config/config.yaml`.
+
+If you are running the node in a home network, you'll want to [forward these ports](https://portforward.com/router.htm),
+then [test the TCP port](https://www.yougetsignal.com/tools/open-ports/). As long as the UDP port forward is set up the
+same way, you expect it to work, as well.
+
+## Grafana
+
+Grafana dashboards are included.
+
+Please see the [secure proxy](../Usage/ReverseProxy.md) docs if you'd like to run Grafana on a secured https port,
+rather than insecure 3000.
+
+## Debug logs
+
+SSV writes debug logs into its docker volume. By default, these can be found in the
+`/var/lib/docker/volumes/eth-docker_ssv-data/_data` directory. `sudo bash` gets you a root shell that has access.
+
+## Updating
+
+When there is a new version of your execution client, consensus client or of the SSV node, just run `./ethd update`
+inside the `ssv-node` directory, which will pull fresh images. Then when you are ready, run `./ethd up` to start using
+the new version(s).
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/SwitchClient.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/SwitchClient.md
new file mode 100644
index 00000000..640e7fec
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/SwitchClient.md
@@ -0,0 +1,306 @@
+---
+id: SwitchClient
+title:  Switching client(s).
+sidebar_label: Switch Clients
+---
+
+## Overview
+
+It may be desirable to switch clients if you are using one that is close to a supermajority of validators. If any one client has a supermajority of the chain, there is a risk that a [consensus bug could lead to a mass slashing](https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/) and validators on this client would lose 3/4th of their staked ETH in that worst-case scenario.  
+
+Choose any consensus client and any execution client you'd like to use, and then follow the instructions below.
+
+Note that if you change the execution client, you either need sufficient disk space to sync two execution clients, or accept downtime while your new execution client syncs.
+
+> `sudo` commands for docker are necessary if your user is not part of the `docker` group. If `docker ps` does not succeed, you need to use `sudo` for `docker` or `docker-compose`, or make your user part of the `docker` group.
+
+## Switching to web3signer
+
+With web3signer, the keys do not need to be moved when switching the consensus client. If keys are currently loaded directly into the validator client, which is the default, they need to be just as carefully moved as when switching between consensus clients without web3signer.
+
+### 1. Delete validator keys
+
+- Verify that you have the keystore-m files to reimport keys after the switch to web3signer. They should be in `./.eth/validator_keys`.
+- Verify that `WEB3SIGNER=false` in .env. If that's not so, **stop** and make it so.
+- `./ethd keys delete all`
+- Verify keys are gone: `./ethd keys list`
+
+### 2. Enable web3signer
+
+- Edit configuration with `nano .env`, set `WEB3SIGNER=true` and add `:web3signer.yml` to `COMPOSE_FILE`.
+- `./ethd up`
+- `./ethd logs -f web3signer` and verify it started correctly
+
+### 3. Delete volume for the old validator client
+
+For all but Nimbus and Teku:
+- `./ethd stop`
+- `docker volume ls` and find the volume that belonged to the old validator client. `docker volume rm` it.
+- `./ethd up`
+
+### 4. Reimport validator keys
+
+This carries a slashing risk, take extreme care.
+
+- [ ] Look at https://beaconcha.in/ and verify that the validator(s) you just removed are now
+  missing an attestation. Take a note of the epoch the last successful attestation was in.
+- [ ] Allow 15 minutes to go by and verify that the last successful attestation's epoch is now
+  finalized. Only then take the next step.
+- [ ] Verify **once more** that all your validator(s) have been down long
+  enough to miss an attestion
+- [ ] If you are absolutely positively sure that the old validator client cannot
+  start attesting again and 15 minutes have passed / **all** validators'
+  last successful attestation is in a finalized epoch, then and only then:
+- [ ] Run `./ethd keys import` and import the keys
+
+### 5. Verify that validators are attesting again
+
+Check https://beaconcha.in/ for your validator public keys, as well as the logs of `consensus` and, if not Nimbus or Teku, `validator` services.
+
+## Switching only the consensus client, keys in web3signer
+
+### 1. Choose a new consensus client
+
+- Reconfigure the stack, either with `nano .env` or `./ethd config`, and choose a new consensus client and the same execution client. Make sure to choose "checkpoint sync" so the consensus client can sync in minutes.
+- Optional: If you set the advanced options `CL_EXTRAS` or `VC_EXTRAS` in `.env`, edit them to conform to the parameters of the new client.
+- `./ethd up`
+- `./ethd logs -f consensus` and verify it went through checkpoint sync and is following chain head
+
+### 2. Delete volumes for the old consensus client
+
+`docker volume ls` and find the volumes that belonged to the old consensus client, and for all but Nimbus and Teku, corresponding validator client. `docker volume rm` those.
+
+### 3. Re-register validator keys
+
+For Teku, Lighthouse and Lodestar, you will need to manually register the keys that are in web3signer. As the keys
+remain in web3signer, this does not carry a slashing risk.
+
+- Run `./ethd keys register`, which will register all keys in web3signer with the new validator client.
+
+Nimbus and Prysm register the web3signer keys automatically on startup, you need not register them manually.
+
+### 4. Verify that validators are attesting
+
+Check https://beaconcha.in/ for your validator public keys, as well as the logs of `consensus` and, if not Nimbus or Teku, `validator` services.
+
+## Switching only the consensus client, keys *not* in web3signer
+
+### 1. Delete validator keys
+
+- Verify that you have the keystore-m files to reimport keys after consensus client switch. They should be in `./.eth/validator_keys`.
+- `./ethd keys delete all`
+
+### 2. Choose a new consensus client
+
+- Reconfigure the stack, either with `nano .env` or `./ethd config`, and choose a new consensus client and the same execution client. Make sure to choose "checkpoint sync" so the consensus client can sync in minutes.
+- Optional: If you set the advanced options `CL_EXTRAS` or `VC_EXTRAS` in `.env`, edit them to conform to the parameters of the new client.
+- `./ethd up`
+- `./ethd logs -f consensus` and verify it went through checkpoint sync and is following chain head
+
+### 3. Delete volumes for the old consensus client
+
+`docker volume ls` and find the volumes that belonged to the old consensus client, and for all but Nimbus and Teku, corresponding validator client. `docker volume rm` those.
+
+### 4. Reimport validator keys
+
+This carries a slashing risk, take extreme care.
+
+- [ ] Look at https://beaconcha.in/ and verify that the validator(s) you just removed are now
+  missing an attestation. Take a note of the epoch the last successful attestation was in.
+- [ ] Allow 15 minutes to go by and verify that the last successful attestation's epoch is now
+  finalized. Only then take the next step.
+- [ ] Verify **once more** that all your validator(s) have been down long
+  enough to miss an attestion
+- [ ] If you are absolutely positively sure that the old validator client cannot
+  start attesting again and 15 minutes have passed / **all** validators'
+  last successful attestation is in a finalized epoch, then and only then:
+- [ ] Run `./ethd keys import` and import the keys
+
+### 5. Verify that validators are attesting again
+
+Check https://beaconcha.in/ for your validator public keys, as well as the logs of `consensus` and, if not Nimbus or Teku, `validator` services.
+
+## Switching the execution client if downtime is acceptable
+
+### 1. Choose a new execution client
+
+- Reconfigure the stack, either with `nano .env` or `./ethd config`, and choose a new execution client and the same consensus client.
+- Optional: If you set the advanced option `EL_EXTRAS` in `.env`, edit it to conform to the parameters of the new client.
+- `./ethd up`
+- `./ethd logs -f execution` and verify it started sync
+
+### 2. Delete volumes for the old execution client
+
+`docker volume ls` and find the volume that belonged to the old execution client. `docker volume rm` it.
+
+### 3. Wait for sync
+
+Depending on the client, sync takes between an hour and 5 days. Once the execution client is fully synced, your validators will start attesting again.
+
+## Switching the execution client while avoiding downtime
+
+### 0. Verify you have sufficient disk space
+
+`df -h` should you enough space to sync a second execution client. ~1 TiB free is usually good. This may be a tall order on a 2TB drive.
+
+### 1. Change the ports of the existing client stack
+
+So that new and old client do not conflict, in the directory for the existing client stack, `nano .env` and adjust `EL_P2P_PORT` and `CL_P2P_PORT` - if using Prysm in old and new location,
+change `PRYSM_PORT` and `PRYSM_UDP_PORT`. "One higher" will work.
+
+Start the existing client stack with `./ethd up`, it will start using the new ports. Peering may be a bit iffy as there is no port forward for the new ports. There is no need to fix that, as it's temporary.
+
+### 2. Create a new client stack
+
+You'll be running a second copy of Eth Docker in its own directory. For example, if the new directory is going to be `~/eth-staker`: `cd ~ && git clone https://github.com/eth-educators/eth-docker.git eth-staker && cd eth-staker` .
+
+Configure the new stack. You can choose the same or a different consensus client, and a different execution client, compared to your existing client stack.
+Make sure to choose "checkpoint sync" so the consensus client can sync in minutes. `./ethd config` followed by `./ethd up`.
+
+**Do not** import validator keys yet. Your validators are still running on your old client, and moving them over needs to be done with care to avoid running them in two places and getting yourself slashed.
+
+Observe consensus client logs with `./ethd logs -f consensus`, see that it checkpoint synced. Look at execution client logs with `./ethd logs -f execution` and wait until it is fully synced. Depending on client this takes between
+1 hour and 5 days.
+
+### 3. Move your validators
+
+**Exercise extreme caution. Running your validators in two locations at once would lead to slashing**
+
+Follow the [moving a validator](../Support/Moving.md) instructions. You'll be inside the old directory, e.g. `~/eth-docker`, for the first part where you delete the keys and make sure they are gone, and inside the new directory, e.g. `~/eth-staker`, for the second part where you import the keys again.
+
+### 4. Shut down the old client and remove its storage
+
+Inside the directory for the old client, e.g. `cd ~/eth-docker`, remove all storage for the client: `./ethd terminate`.
+
+Finally, you can remove the directory itself: For example, if it was `~/eth-docker`, `cd ~ && rm -rf eth-docker`.
+
+## Switching clients from systemd to Eth Docker
+
+If you are using systemd with guides from Somer Esat, Coincashew or Metanull, and want to give Eth Docker's automation a whirl, these instructions will show you how to make the switch.
+
+### 1. Create a new Eth Docker client stack
+
+Clone Eth Docker, for example into `~/eth-docker`: `cd ~ && git clone https://github.com/eth-educators/eth-docker.git && cd eth-docker` .
+
+Install prerequisites: `./ethd install`
+
+Configure the client stack. "Rapid sync" can let the consensus layer client sync in minutes. `./ethd config`, followed by `./ethd up`.
+
+**Do not** import validator keys yet. Your validators are still running on your old client, and moving them over needs to be done with care to avoid running them in two places and getting yourself slashed.
+
+Observe the consensus client, and make sure it is synchronizing: `./ethd logs -f consensus`.
+
+### 1a. Optional: Move the existing execution client database to its new location
+
+This only works if you've chosen the same execution client in Eth Docker as you are running in systemd. This avoids a fresh sync of the execution client database in the new location. Note you might want to fresh sync if your DB has grown to the point where starting over is beneficial.
+
+In the location for the new client stack, e.g. `~/eth-docker`, stop the stack: `./ethd stop`
+
+`docker volume ls` to see the volume name of the new execution client. For Geth, you might see `eth-docker_geth-eth1-data`.
+
+Remove the partially synced contents of the new database location: `sudo rm -rf /var/lib/docker/volumes/NEWVOLUME/_data`, e,g. for Geth `sudo rm -rf /var/lib/docker/volumes/eth-docker_geth-eth1-data/_data`
+
+Move the directory of the systemd EL database to the new database location. This depends on what execution layer client you are using. This example assumes Geth.
+
+#### Somer Esat's guide
+ 
+Disable the Geth service and move its database: `sudo systemctl disable geth` and `sudo mv /var/lib/goethereum -t /var/lib/docker/volumes/eth-docker_geth-eth1-data`.
+
+#### Metanull's guide
+
+Disable the Geth service and move its database: `sudo systemctl disable geth` and `sudo mv /home/geth/* -t /var/lib/docker/volumes/eth-docker_geth-eth1-data`.
+
+#### Coincashew's guide
+
+Disable the Geth service and move its database: `sudo systemctl disable eth1` and `sudo mv ~/.ethereum -t /var/lib/docker/volumes/eth-docker_geth-eth1-data`.
+
+#### Change permissions and start the stack
+
+Change permissions so Eth Docker can access the Geth database: `sudo chown -R 10001:10001 /var/lib/docker/volumes/eth-docker_geth-eth1-data`
+
+Start the new stack again: `./ethd up`, then observe that your execution client is running well and is synced to head: `./ethd logs -f execution`.
+
+### 1b. If you did not move Geth with 1a: Shut down Geth
+
+This will stop your validators from attesting. You will incur downtime until the new execution layer database has been fully synced.
+
+#### Somer Esat's guide
+ 
+Disable the Geth service and remove its database: `sudo systemctl disable geth` and `sudo rm -rf /var/lib/goethereum`.
+
+#### Metanull's guide
+
+Disable the Geth service and remove its database: `sudo systemctl disable geth` and `sudo rm -rf /home/geth/*`.
+
+#### Coincashew's guide
+
+Disable the Geth service and remove its database: `sudo systemctl disable eth1` and `sudo rm -rf ~/.ethereum`.
+
+### 2. Move your validators
+
+**Exercise extreme caution. Running your validators in two locations at once would lead to slashing**
+
+Make sure you have your `keystore-m_ETC.json` files and the password for them. Ideally, you should also have a `slashing-protection.json` file.
+
+Stop the validator service. Somer Esat: `sudo systemctl stop prysmvalidator`. Metanull and Coincashew: `sudo systemctl stop validator`.
+
+To export the slashing protection DB from Prysm, adjust this command line to your username and location Eth Docker is in and run `sudo validator slashing-protection-history export --datadir=/var/lib/prysm/validator --slashing-protection-export-dir=/home/ubuntu/eth-docker/.eth/validator_keys`
+
+To export the keys from Prysm, run `sudo validator accounts backup --wallet-dir=/var/lib/prysm/validator --backup-dir=/tmp/keys` and then move them to the `eth-docker` directory, again adjusting for your username: `sudo unzip /tmp/keys/backup.zip -d /home/ubuntu/eth-docker/.eth/validator_keys`. Lastly, remove the zip file again: `sudo rm /tmp/keys/backup.zip`
+ 
+#### Somer Esat's guide
+
+First, remove the validator keys from the existing setup. `sudo systemctl stop prysmvalidator`. Remove the keys: `sudo rm -rf /var/lib/prysm/validator`. 
+
+Verify that the validator can't find them: `sudo systemctl start prysmvalidator` and `journalctl -fu prysmvalidator`, observe that it complains it cannot find its keys. **Do not proceed if the keys are still accessible to the validator**
+
+`sudo systemctl stop prysmvalidator` and `sudo systemctl disable prysmvalidator` to shut it down for good.
+
+Follow the [moving a validator](../Support/Moving.md#import-keys-into-new-client) instructions. You already removed the keys: Wait 15 minutes after that to protect against slashing, then import them again from inside the `~/eth-docker` directory.
+
+#### Metanull's guide
+
+First, remove the validator keys from the existing setup. `sudo systemctl stop validator`. Remove the keys: `sudo rm -rf /home/validator/.eth2validators`
+
+Verify that the validator can't find them: `sudo systemctl start validator` and `journalctl -fu validator`, observe that it complains it cannot find its keys. **Do not proceed if the keys are still accessible to the validator**
+
+`sudo systemctl stop validator` and `sudo systemctl disable validator` to shut it down for good.
+
+Follow the [moving a validator](../Support/Moving.md#import-keys-into-new-client) instructions. You already removed the keys: Wait 15 minutes after that to protect against slashing, then import them again from inside the `~/eth-docker` directory.
+
+#### Coincashew's guide
+
+First, remove the validator keys from the existing setup. `sudo systemctl stop validator`. Remove the keys: `sudo rm -rf ~/.eth2validators`.
+
+Verify that the validator can't find them: `sudo systemctl start validator` and `journalctl -fu validator`, observe that it complains it cannot find its keys. **Do not proceed if the keys are still accessible to the validator**
+
+`sudo systemctl stop validator` and `sudo systemctl disable validator` to shut it down for good.
+
+Follow the [moving a validator](../Support/Moving.md#import-keys-into-new-client) instructions. You already removed the keys: Wait 15 minutes after that to protect against slashing, then import them again from inside the `~/eth-docker` directory.
+
+### 3. Remove old beacon database
+
+We can remove the old beacon chain database and disable the service.
+
+#### Somer Esat's guide
+
+`sudo systemctl stop prysmbeacon && sudo systemctl disable prysmbeacon` and `sudo rm -rf /var/lib/prysm`.
+
+Optionally, remove the goeth and prysm users: `sudo deluser goeth && sudo deluser prysmbeacon && sudo deluser prysmvalidator`.
+
+Optionally, remove the old executables: `sudo apt remove -y geth && sudo apt -y auto-remove && sudo rm /usr/local/bin/validator && sudo rm /usr/local/bin/beacon-chain`.
+
+
+#### Metanull's guide
+
+`sudo systemctl stop beacon-chain && sudo systemctl disable beacon-chain` and `sudo rm -rf /home/beacon/*`.
+
+Optionally, remove the geth and prysm users: `sudo deluser --remove-home geth && sudo deluser --remove-home beacon && sudo deluser --remove-home validator`.
+
+Optionally, remove the old Geth package: `sudo apt remove -y ethereum && sudo apt -y auto-remove`.
+
+#### Coincashew's guide
+
+`sudo systemctl stop beacon-chain && sudo systemctl disable beacon-chain` and `sudo rm -rf ~/prysm`.
+
+Optionally, remove the old Geth package: `sudo apt remove -y ethereum && sudo apt -y auto-remove`.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Troubleshooting.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Troubleshooting.md
new file mode 100644
index 00000000..0f3ee814
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Troubleshooting.md
@@ -0,0 +1,84 @@
+---
+id: Troubleshooting
+title:  Troubleshooting.
+sidebar_label: Troubleshooting
+---
+
+As always, add `sudo` to these commands if your user is not part of the `docker` group.
+
+## Visibility
+
+`./ethd logs -f consensus` and `./ethd logs -f execution` or more broadly `./ethd logs -f <servicename>` will show you logs. When the service has been running for a while, you may want to start at the end, like so: `./ethd logs -f --tail 50 consensus`.
+
+`docker ps` will show you a list of running containers and their mapped ports.
+
+## Stopping and starting, updating
+
+`./ethd stop` stops all services, `./ethd up` starts them. `./ethd restart` does both. `./ethd update` brings in updates to the clients, `./ethd update --refresh-targets` does that while resetting docker tag targets in `.env` to defaults.
+
+## Targets, source build
+
+There are build targets in `.env` which, for the most part, you need not touch. For Lighthouse in particular, if your CPU is older than Broadwell (2014), you'll want the `latest` target, not `latest-modern`. Change `LH_DOCKER_TAG=latest` in `.env` and run `./ethd update`, then `./ethd up`.
+
+If you want to build from source, change to `Dockerfile.source` instead of `Dockerfile.binary` for that particular client. The default source targets use the latest released tag on github; adjust to whichever tag or branch you want to build from.
+
+## Remove all traces of the client
+
+This project uses docker volumes to store the Ethereum PoW and PoS databases, as
+well as validator keys for the validator client. `./ethd terminate` will remove all
+volumes. 
+
+If you prefer to do that manually, you can see the volumes with
+`docker volume ls` and remove them with `docker volume rm`, as long as they are
+not in use.
+
+This can be useful when moving between testnets or from a testnet to main net, without
+changing the directory name the project is stored in; or when you want to start over
+with a fresh database. Keep in mind that synchronizing Ethereum 1 can take days on main
+net, however.
+
+> **Caution** If you are removing the client to recreate it, please be careful
+> to wait 15 minutes before importing validator key(s) and starting it again.
+> The slashing protection DB will be gone, and you risk slashing your validator(s)
+> otherwise.
+
+## Using Eth Docker with a VPN on the node
+
+VPNs typically need IP addressing in the RFC1918 (private) range, and docker by default will utilize the entire range, leaving the VPN to not find a free prefix.
+
+This can be solved by [changing the configuration of Docker](https://docs.storagemadeeasy.com/appliance/docker_networking) to use only a portion of RFC1918 for its address pool.
+
+## Interacting with Docker directly
+
+`./ethd cmd` runs `docker-compose` or `docker compose`, depending on the compose version, and will use `sudo` as required. You can also run compose commands without using the `./ethd` wrapper.
+
+`docker-compose stop servicename` brings a service down, for example `docker-compose stop validator`.<br />
+`docker-compose down` will stop the entire stack.<br />
+`docker-compose up -d servicename` starts a single service, for example `docker-compose up -d validator`.
+The `-d` means "detached", not connected to your input session.<br />
+`docker-compose run servicename` starts a single service and connects your input session to it. Use the Ctrl-p Ctrl-q
+key sequence to detach from it again.
+
+`docker ps` lists all running services, with the container name to the right.<br />
+`docker logs containername` shows logs for a container, `docker logs -f --tail 500 containername` scrolls them.<br />
+`docker-compose logs servicename` shows logs for a service, `docker-compose logs -f --tail 500 servicename` scrolls them.<br />
+`docker exec -it containername bash` will connect you to a running service in a bash shell.
+
+You may start a service with `docker-compose up -d servicename` and then find it's not in `docker ps`. That means it terminated while trying to start. To investigate, you could leave the `-d` off so you see logs on command line:<br />
+`docker-compose up consensus`, for example.<br />
+You could also run `docker-compose logs --tail 100 consensus` to see the last logs of that service and the reason it terminated.<br />
+
+If a service is not starting and you want to bring up its container manually, so you can investigate, first bring everything down:<br />
+`docker-compose down`, tear down everything first.<br />
+`docker ps`, make sure everything is down.<br />
+
+If you need to see the files that are being stored by services such as consensus, validator, execution, grafana, &c, in Ubuntu Linux you can find those in /var/lib/docker/volumes. `sudo bash` to invoke a shell that has access.
+
+**HERE BE DRAGONS** You can totally run N copies of an image manually and then successfully start a validator in each and get yourself slashed if the built-in database lock fails.
+Take extreme care.
+
+Once your stack is down, to run an image and get into a shell, without executing the client automatically:<br />
+`docker run -it --entrypoint=/bin/bash imagename`, for example `docker run -it --entrypoint=/bin/bash lighthouse:local`.<br />
+You'd then run Linux commands manually in there, you could start components of the client manually. There is one image per client.<br />
+`docker images` will show you all images.
+
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Update.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Update.md
new file mode 100644
index 00000000..bcb4f14c
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Update.md
@@ -0,0 +1,59 @@
+---
+id: Update
+title:  Updating the software.
+
+sidebar_label: Client Updates
+---
+
+This project does not monitor client versions. It is up to you to decide that you
+are going to update a component. When you are ready to do so, the below instructions
+show you how to.
+
+You can find the current version of your client by running `./ethd version`, assuming the
+node is up and running
+
+## Automated update
+
+Inside the project directory, run:<br />
+`./ethd update`
+
+This will update Eth Docker, all Ethereum clients, and migrate your `.env` settings over to a fresh copy
+from `default.env`.
+
+If you want to reset your client version targets, run `./ethd update --refresh-targets` instead.
+
+Restart changed containers with `./ethd up`.
+
+## Optional: Manually update Eth Docker
+
+Inside the project directory, run:<br />
+`git pull`
+
+Then `cp .env .env.bak` and `cp default.env .env`, and set variables inside `.env`
+the way you need them, with `.env.bak` as a guide.
+
+Updating the tool itself is not always necessary. Please refer to the [Changelog](../About/Changelog.md) to see
+whether changes have been made that you may want to use.
+
+## Optional: Manually update the client "stack"
+
+If you are using binary build files - the default - you can update everything
+in the client "stack" with `./ethd cmd build --pull`. If you
+run shared components in a different directory, such as the execution client,
+you'd `cd` into those directories and run the command there.
+
+And restart changed containers: `./ethd up`
+
+Then verify that the components are coming up okay again by looking at logs:
+- `./ethd logs -f consensus` for the consensus client
+- `./ethd logs -f validator` for the validator, if using Lighthouse or Prysm
+- `./ethd logs -f execution` for the execution client, if you are running one locally
+
+## Optional: Update just the execution client, instead of the entire "stack"
+
+Run:<br />
+`./ethd cmd build --pull execution`
+
+Then stop, remove and start the execution client:<br />
+`./ethd cmd stop execution && ./ethd cmd rm execution`<br />
+`./ethd up`
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Windows.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Windows.md
new file mode 100644
index 00000000..a39f4a87
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/Windows.md
@@ -0,0 +1,103 @@
+---
+id: Windows
+title:  Windows
+sidebar_label: Windows
+---
+
+Windows may seem like an "easy button". For Eth Docker, it is anything but, and even running native Windows clients
+presents multiple challenges. They can all be overcome, and the
+[eth-wizard project](https://github.com/stake-house/eth-wizard) aims to do just that.
+
+If you wish to run Eth Docker on Windows regardless, this is what's required.
+
+- Windows 11 Pro 22H2 build 22621.2428 (KB5031354 October 2023) or later, ideally with 64 GiB RAM so that WSL defaults
+to 30 GiB
+- [WSL 2](https://learn.microsoft.com/en-us/windows/wsl/about), the "Windows Subsystem for Linux", which runs a Linux
+kernel in a lightweight VM
+- WSL networking that is reachable from the LAN
+- Functioning time sync
+- Docker Desktop, with Windows configured to start it on boot
+
+These are the configuration steps:
+
+Windows
+- Verify you are running Windows 11 Pro 22H2 build 22621.2428 or later and have sufficient RAM
+- To keep the system secure, configure Windows Update to download and apply patches automatically, and to update WSL.
+Settings -> Windows Update -> Advanced, enable "Receive updates for other Microsoft products" and "Get me up to date".
+
+WSL
+- From Windows Store, install WSL and Ubuntu current LTS. Debian is also an option, it is however quite bare-bones
+without even man-db out of the box.
+- This defaults to WSL 2, but if you have an older WSL 1 install, find it with `wsl --list -v` and change it with
+`wsl --set-version DISTRO-NAME 2` as well as `wsl --set-default-version 2`.
+- Install WSL [2.2.4](https://github.com/microsoft/WSL/releases) or later. It should come in automatically with Windows
+Update, and can also be updated in PowerShell with `wsl --update`.
+- Increase the disk space available to WSL [from 1TB to 3TB](https://learn.microsoft.com/en-us/windows/wsl/disk-space).
+- Create a scheduled task in Task Scheduler to keep Ubuntu/Debian in WSL updated.
+  - Call it WSLUpdate
+  - Run every day at a time you like
+  - Run only if any network is connected
+  - Run as soon as possible if a start was missed
+  - Stop task if it runs longer than 1 hour
+  - Create two "Start Program" actions
+    - The first is `wsl.exe -u root -e apt-get update`
+    - The second is `wsl.exe -u root DEBIAN_FRONTEND=noninteractive apt-get -y --autoremove dist-upgrade`
+
+WSL Networking
+- Configure WSL for [mirrored networking](https://github.com/microsoft/WSL/releases/tag/2.0.0). Edit `.wslconfig` in
+your Windows home directory and add
+```
+[wsl2]
+networkingMode=mirrored
+```
+- Mirrored networking shares the MAC address, IPv4 address and IPv6 address of the Windows host machine. On your
+router, set a DHCP reservation for this machine so WSL always has the same local IP; or configure Windows with a static
+IP. This makes port forwarding of the P2P ports possible, and makes remote access easier.
+- Check memory assigned to WSL with `free -h`. If it's too low for your chosen client mix, edit `.wslconfig` in your
+Windows home directory and add a memory section, for example
+```
+[wsl2]
+memory=32GB
+```
+
+Time sync
+- Fix Windows time sync if your machine is not domain-joined
+  - Change w32time to [start automatically](https://docs.microsoft.com/en-us/troubleshoot/windows-client/identity/w32time-not-start-on-workgroup). In Administrator cmd, but **not** PowerShell, `sc triggerinfo w32time start/networkon stop/networkoff`. Verify with `sc qtriggerinfo w32time`. To get into cmd that way, you can start Admin PowerShell and then just type `cmd`.
+  - In `Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config`, set `MaxPollInterval` to hex `c`, decimal `12`.
+  - Check `Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Parameters\NtpServer`. If it ends in `0x9` you are done. If it ends in `0x1` you need to adjust `SpecialPollInterval` in `Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient` to read `3600`
+  - Reboot, then from Powershell run `w32tm /query /status /verbose` to verify that w32time service did start. If it didn't, check triggers again. If all else fails, set it to Automatic Delayed startup
+- [Enable systemd](https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/#set-the-systemd-flag-set-in-your-wsl-distro-settings)
+for WSL. In WSL, run `sudo nano /etc/wsl.conf` and add:
+```
+[boot]
+systemd=true
+```
+Close your WSL windows and in Powershell, run `wsl --shutdown`. When it launches again, systemd should be running.
+- Install chrony with `sudo apt install -y chrony`.
+- If despite chrony, you still see [clock skew](https://github.com/microsoft/WSL/issues/10006) in WSL, set a scheduled
+task to keep WSL in sync with your Windows clock. From non-admin Powershell, run
+`schtasks /Create /TN WSLTimeSync /TR "wsl -u root hwclock -s" /SC ONEVENT /EC System /MO "*[System[Provider[@Name='Microsoft-Windows-Kernel-Power'] and (EventID=107 or EventID=507) or Provider[@Name='Microsoft-Windows-Kernel-General'] and (EventID=1)]]" /F`.
+
+Docker Desktop
+- Install [Docker Desktop](https://www.docker.com/products/docker-desktop/).
+- Configure it to start on login, but not to open the Docker Dashboard on start.
+- It should default to use the WSL 2 based engine.
+- Configure Docker Desktop to download patches automatically. Applying them may be a manual step.
+- Your node needs to run after Windows reboot for 24/7 uptime. Docker Desktop only starts well with a logged-in user.
+To solve this, use [Windows ARSO](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/winlogon-automatic-restart-sign-on--arso-).
+  - Start group policy editor, find "Computer Configuration > Administrative Templates > Windows Components > Windows sign in Options"
+and enable "Sign-in and lock last interactive user automatically after a restart"
+  - If you are not using Bitlocker, you may also need "Configure the mode of automatically signing in and locking last interactive user after a restart or cold boot".
+I was unable to configure this from the GUI and ended up using RegEdit. Navigate to
+`HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System` and create a new DWORD called
+`AutomaticRestartSignOnConfig`. Set it to `0` if you use BitLocker, and to `1` if you are not.
+
+QoL
+- Optional: Improve your WSL experience with [Windows Terminal and oh-my-zsh](https://gist.github.com/zachrank/fc71ed301e9823264ddac4fb77975735)
+- Optional: Use sparse VHD for WSL, `wsl.exe --list` and then `wsl.exe --manage DISTRO-NAME --set-sparse true`. I
+have not tested the performance impact of this.
+- Optional: Configure your Windows drive to be [encrypted with Bitlocker](https://www.windowscentral.com/how-use-bitlocker-encryption-windows-10).
+Be very careful to print out the recovery key and keep it safe. Always suspend Bitlocker before doing a UEFI/BIOS
+upgrade.
+
+From here, you should be able to configure Eth Docker as usual, see [Quick Start](../Usage/QuickStart.md).
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/ipv6.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/ipv6.md
new file mode 100644
index 00000000..bfa7a02c
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Support/ipv6.md
@@ -0,0 +1,64 @@
+---
+id: ipv6
+title: IPv6
+sidebar_label: IPv6 support
+---
+
+## Y tho
+
+As of mid 2024:
+
+CGNAT is becoming more prevalant, making it harder to make P2P ports available inbound and get good peering.
+
+Docker support for IPv6 is better.
+
+Ethereum clients are starting to add v6 support, which can benefit from testing.
+
+## How then
+
+### Check you have v6
+
+You can test, from a PC on your LAN, that [whatismyip](https://whatismyip.com) shows both a public v6 and v4 address.
+If so, your router is set correctly. This will likely be the case "out of the box" on any ISP that uses CGNAT, and on
+several that don't, like Comcast in the US.
+
+On your node, `ip address show` should show you both a v4 `inet` and public v6 `inet6` address on the interface. If
+all you see is an `fe80::` address for inet6, you don't have a routable v6 address configured, and you'll want to fix
+that, first.
+
+### Configure Docker
+
+You'll want to be on the latest version of docker-ce, at least `27.0.1`.
+
+If you previously had IPv6-specific settings in `/etc/docker/daemon.json`, you can remove them now.
+
+### Configure Eth Docker
+
+`nano .env` and set `IPV6=true`, which will tell Compose to enable v6 for the networks it creates.
+
+## Safu?
+
+Maybe. I still have to test ufw integration.  
+On your LAN firewall, if this is in a LAN, you'd need rules to allow the P2P ports incoming to the v6 address of your
+node.
+
+## Which clients?
+
+CL
+
+- [x] Lighthouse
+- [x] Lodestar
+- [x] Nimbus
+- [ ] Teku: Unsure, advertisement not tested
+- [ ] Prysm: Maybe, `--p2p-local-ip ::`, but [not dual-stack](https://github.com/prysmaticlabs/prysm/issues/12303)
+- [ ] Grandine: Unsure
+- [ ] Lambda: Unsure
+
+EL
+
+- [ ] Besu: not fully tested
+- [ ] Geth: not fully tested
+- [ ] Erigon: not fully tested
+- [ ] Nethermind: Possibly no advertisement, no explicit discv5 option
+- [ ] Reth: No IPv6 connectivity on `main` as of mid Nov 2023
+- [ ] Nimbus: Unsure
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/ClientSetup.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/ClientSetup.md
new file mode 100644
index 00000000..cb18559f
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/ClientSetup.md
@@ -0,0 +1,192 @@
+---
+id: Advanced
+title: "Advanced use and manual setup"
+sidebar_label: Advanced Use
+---
+
+## Client choice - manual setup
+
+> You can refer back to the [Overview](/) to get a sense of how the
+> validator client, consensus client and execution client are
+> connected to each other, and which role each plays.
+
+Please choose:
+
+* The consensus client you wish to run
+  * Lodestar
+  * Nimbus
+  * Teku
+  * Grandine
+  * Lighthouse
+  * Prysm
+  * Caplin - built into Erigon
+* Your execution client you wish to run
+  * Reth
+  * Besu
+  * Nethermind
+  * Geth
+  * Erigon
+* Whether to run a grafana dashboard for monitoring
+
+First, copy the environment file.  
+`cp default.env .env`
+
+> This file is called `.env` (dot env), and that name has to be exact. docker compose
+will otherwise show errors about not being able to find a `docker-compose.yml` file,
+which this project does not use.
+ 
+Then, adjust the contents of `.env`. On Ubuntu Linux, you can run `nano .env`.
+
+- Set the `COMPOSE_FILE` entry depending on the client you are going to run,
+and with which options. See below for available compose files. Think of this as
+blocks you combine: One consensus client, optionally one execution client, optionally reporting,
+optionally a reverse proxy for https:// access to reporting.
+- Set the `NETWORK` variable to either "mainnet" or a test network such as "goerli"
+- Set the `GRAFFITI` string if you want a specific string.
+- If you are going to run a validator client only, without a consensus client, set `CL_NODE` to the URL of your
+Ethereum PoS beacon, and choose one of the `CLIENT-vc-only.yml` entries in `COMPOSE_FILE`.
+- If you are going to send statistics to https://beaconcha.in, set `BEACON_STATS_API` to your API key
+- If you want to sync the consensus client quickly, set `RAPID_SYNC_URL` to a checkpoint provider such as checkpointz
+- Adjust ports if you are going to need custom ports instead of the defaults. These are the ports
+exposed to the host, and for the P2P ports to the Internet via your firewall/router.
+
+## Compose files
+
+The main concept to understand is that all files in `COMPOSE_FILE` inside `.env` are combined in order, and Docker
+Compose will then act on the resulting config. It can be viewed with `docker compose config`.
+
+Set the `COMPOSE_FILE` string depending on which client you are going to use. Add optional services with `:` between
+the file names.
+
+Choose one consensus client:
+
+- `teku.yml` - Teku
+- `lodestar.yml` - Lodestar
+- `nimbus.yml` - Nimbus
+- `lighthouse.yml` - Lighthouse
+- `prysm.yml` - Prysm
+
+Choose one execution client:
+
+- `reth.yml` - Reth
+- `besu.yml` - Besu
+- `nethermind.yml` - Nethermind
+- `erigon.yml` - Erigon execution client
+- `geth.yml` - Geth execution client
+
+> If you wish to use the built-in Caplin consensus client with Erigon, use `erigon.yml` without a consensus client file,
+and it will use the built-in Caplin consensus client
+
+Optionally, enable MEV boost:
+
+- `mev-boost.yml` - add the mev-boost sidecar
+
+Optionally, choose a reporting package:
+
+- `grafana.yml` - Enable local Grafana dashboards
+- `grafana-cloud.yml` - Run a local Prometheus with support for remote-write to Grafana Cloud
+
+- `grafana-shared.yml` - to map the local Grafana port (default: 3000) to the host. This is not encrypted and should
+not be exposed to the Internet. Used *in addition* to `grafana.yml`, not instead. Using encryption instead via
+`traefik-*.yml` is recommended.
+- `prysm-web-shared.yml` - to map the Prysm web port (default: 3500) to the host. This is not encrypted and should
+not be exposed to the Internet. Using encryption instead via `traefik-*.yml` is recommended.
+- `siren.yml` - Lighthouse's Siren UI
+
+> See [Prysm Web](../Usage/PrysmWeb.md) for notes on using the Prysm Web UI
+
+Optionally, add ethdo for beacon chain queries:
+
+- `ethdo.yml` - add Attestant's ethdo tool for querying your consensus layer aka beacon node
+
+Optionally, make the staking-deposit-cli available:
+
+- `deposit-cli.yml` - Used to generate mnemonics and signing keys. Consider running key generation offline, instead,
+and copying the generated `keystore-m` files into this tool.
+
+Optionally, add encryption to the Grafana and/or Prysm Web pages:
+
+- `traefik-cf.yml` - use encrypting secure web proxy and use CloudFlare for DNS management
+- `traefik-aws.yml` - use encrypting secure web proxy and use AWS Route53 for DNS management
+- `el-traefik.yml,` `cl-traefik.yml`, `ee-traefik.yml` - advanced use, use traefik for access to execution RPC,
+consensus REST and execution engine RPC API ports respectively. Be very cautious with these, always
+[firewall](../Support/Cloud.md) that access to trusted source IPs.
+
+With these, you wouldn't use the `-shared.yml` files. Please see [Secure Web Proxy Instructions](../Usage/ReverseProxy.md)
+for setup instructions for either option.
+
+For example, Teku with Besu:
+`COMPOSE_FILE=teku.yml:besu.yml`
+
+## Sharing RPC and REST ports
+
+These are largely for running RPC nodes, instead of validator nodes. Most users will not require them.
+
+The `SHARE_IP` variable in `.env` can be used to restrict these shares to `127.0.0.1`, for local use or for use
+with an SSH tunnel.
+
+- `el-shared.yml` - as an insecure alternative to traefik-\*.yml, makes the RPC and WS ports of the execution client
+available from the host. To be used alongside one of the execution client yml files. **Not encrypted**, do not expose
+to Internet.
+- `cl-shared.yml` - as an insecure alternative to traefik-\*.yml, makes the REST port of the consensus client available
+from the host. To be used alongside one of the consensus client yml files. **Not encrypted**, do not expose to Internet.
+- `ee-shared.yml` - as an insecure alternative to traefik-\*.yml, makes the engine API port of the execution client
+available from the host. To be used alongside one of the execution client yml files. **Not encrypted**, do not expose
+to Internet.
+
+- `CLIENT-cl-only.yml` - for running a [distributed consensus client and validator client](../Usage/ReverseProxy.md)
+setup.
+- `CLIENT-vc-only.yml` - the other side of the distributed client setup.
+
+## MEV Boost
+
+Your Consensus Layer client connects to the mev-boost container. If you are running a CL in Eth Docker, then in `.env`
+you'd add `mev-boost.yml` to `COMPOSE_FILE`, set `MEV_BOOST=true` and set `MEV_RELAYS` to the
+[relays you wish to use](https://ethstaker.cc/mev-relay-list/).
+
+If you would like to ensure whether your MEV relay has registered your validator, follow the documentation for your chosen relays. For instance, if you have included Flashbots, you can see whether your validator has been registered by querying their API. Add your validator's public key to the end of this endpoint: https://boost-relay.flashbots.net/relay/v1/data/validator_registration?pubkey=
+
+
+If you are running a validator client only, such as with a RocketPool "reverse hybrid" setup, then all you need to do
+is to set `MEV_BOOST=true` in `.env`. `mev-boost.yml` and `MEV_RELAYS` are not needed and won't be used if they are
+set, as they are relevant only where the Consensus Layer client runs. See the [Overview](/) drawing for how these
+components communicate.
+
+## Specialty yml files
+
+Eth Docker supports some specialty use cases. These are the corresponding yml files.
+
+- `ext-network.yml` - Connect to another Docker network, for example for reverse hybrid with RocketPool or connecting
+to a central traefik/prometheus.
+- `v6-network.yml` - part of enabling IPv6 support
+ - `central-metrics.yml` - Scrape metrics from a
+[central prometheus](https://github.com/CryptoManufaktur-io/central-proxy-docker)
+- `nimbus-stats.yml` - Send Nimbus stats to beaconcha.in app
+- `prysm-stats.yml` - Send Prysm stats to beaconcha.in app
+- `ssv.yml` - Run an SSV DVT node
+
+## Multiple nodes on one host
+
+In this setup, clients are isolated from each other. Each run their own validator client, and if an execution client
+is in use, their own execution client. This is perfect for running a single client, or multiple isolated
+clients each in their own directory.
+
+If you want to run multiple isolated clients, just clone this project into a new directory for
+each. This is great for running testnet and mainnet in parallel, for example.
+
+## Prysm or Lighthouse Slasher
+
+Running [slasher](https://docs.prylabs.network/docs/prysm-usage/slasher/) is an optional setting in `.env`, and helps
+secure the chain. There are [no additional earnings](https://github.com/ethereum/consensus-specs/issues/1631) from
+running a slasher: Whistleblower rewards are not implemented, and may not ever be implemented.
+
+> Slasher can be a huge resource hog during times of no chain finality, which can manifest as massive RAM usage. Please
+make sure you understand the risks of this, especially if you want high uptime for your Ethereum staking full node.
+Slasher places significant stress on the consensus client when the chain has no finality, and might be the reason why
+your validators are underperforming if your consensus client is under this much stress.
+
+To run a slasher, add the relevant command(s) to `CL_EXTRAS` in your `.env` file.
+
+## Build the client
+
+Build all required images. `./ethd update`
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/Dashboards.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/Dashboards.md
new file mode 100644
index 00000000..6c0d8d07
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/Dashboards.md
@@ -0,0 +1,60 @@
+---
+id: Dashboards
+title: "Step 7: Choose a Grafana dashboard (optional)"
+sidebar_label: Dashboards
+---
+
+## Choose local or cloud Grafana
+
+You have a choice of running Grafana locally, by including `grafana.yml`, or in the cloud, with `grafana-cloud.yml`.
+If you choose Grafana Cloud, you **must** edit `prometheus/custom-prom.yml` and add your cloud remote write
+credentials. Please see `prometheus/custom-prom.yml.sample` for the syntax of that addition.
+
+`grafana-cloud.yml` runs a local Prometheus but no local Grafana, and enables adding custom Prometheus config items.
+Its contents are merged with the pre-provisioned configuration.
+
+If you want to add additional scrape targets, place these into `prometheus/conf.d`.
+
+## Local Grafana dashboards
+
+A baseline set of dashboards has been included.  
+- [Metanull's Prysm Dashboard JSON](https://raw.githubusercontent.com/metanull-operator/eth2-grafana/master/eth2-grafana-dashboard-single-source-beacon_node.json)
+- [Prysm Dashboard JSON](https://raw.githubusercontent.com/GuillaumeMiralles/prysm-grafana-dashboard/master/less_10_validators.json)
+- [Prysm Dashboard JSON for more than 10 validators](https://raw.githubusercontent.com/GuillaumeMiralles/prysm-grafana-dashboard/master/more_10_validators.json)
+- [Lighthouse Beacon Dashboard JSON](https://raw.githubusercontent.com/sigp/lighthouse-metrics/master/dashboards/Summary.json)
+- [Lighthouse Validator Client Dashboard JSON](https://raw.githubusercontent.com/sigp/lighthouse-metrics/master/dashboards/ValidatorClient.json)
+- [Lighthouse Yoldark34 Dashboard JSON](https://raw.githubusercontent.com/Yoldark34/lighthouse-staking-dashboard/main/Yoldark_ETH_staking_dashboard.json)
+- [Nimbus Dashboard JSON](https://raw.githubusercontent.com/status-im/nimbus-eth2/master/grafana/beacon_nodes_Grafana_dashboard.json)
+- [Teku Dashboard JSON](https://grafana.com/api/dashboards/12199/revisions/1/download)
+- [Geth Dashboard JSON](https://gist.githubusercontent.com/karalabe/e7ca79abdec54755ceae09c08bd090cd/raw/3a400ab90f9402f2233280afd086cb9d6aac2111/dashboard.json)
+- [Lodestar Dashboard JSON](https://raw.githubusercontent.com/ChainSafe/lodestar/stable/dashboards/lodestar_summary.json)
+- [Reth Dashboard JSON](https://raw.githubusercontent.com/paradigmxyz/reth/main/etc/grafana/dashboards/overview.json)
+
+You can additional dashboards from the Grafana repository, for example `11133` as a node exporter dashboard. You can
+also import dashboards by their JSON, as you see fit.
+
+## Connecting to local Grafana  
+
+Connect to https://grafana.yourdomain.com/ (or http://YOURSERVERIP:3000/ if not using the reverse proxy), log in as
+admin/admin, and set a new password.
+
+> If you run Grafana over http without encryption, do not expose the Grafana port to the Internet. You can
+> use [SSH tunneling](https://www.howtogeek.com/168145/how-to-use-ssh-tunneling/) to reach Grafana securely over the Internet.
+
+In order to load other Dashboards, follow these instructions.
+
+- Click on the + icon on the left, choose "Import".
+- Copy/paste JSON code from the Raw github page of the Dashboard you chose - click anywhere inside the page, use Ctrl-A
+to select all and Ctrl-C to copy
+- Click "Load"
+- If prompted for a data source choose the "prometheus" data source
+- Click "Import".
+
+## Alerting with Grafana
+
+Grafana supports setting up alerts and sending notifications to email, Slack, Discord, PagerDuty, etc. Some alerts
+are pre-previsioned.
+
+To receive these alerts, use the alert bell icon on the left-hand side and set up contact points and notification
+policies. The pre-provisioned alerts use a `severity` label. You could for example send `medium` severity alerts to
+email, Discord or Telegram, and `critical` severity alerts to PagerDuty or OpsGenie.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/Hardware.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/Hardware.md
new file mode 100644
index 00000000..cc8d094f
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/Hardware.md
@@ -0,0 +1,98 @@
+---
+id: Hardware
+title: Resources, hardware
+sidebar_label: Hardware
+---
+
+Recommended hardware:
+* 32 GiB of RAM - 16 GiB works but can be challenging depending on client mix
+* Quad Core CPU
+* 4TB ["mainstream" SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038) - TLC and DRAM
+
+Generally, 8 GiB of RAM is a very tight fit, with only Nimbus/Geth reported to work. 16 GiB can be a tight fit
+depending on client mix, and 32 GiB is recommended. For 16 GiB RAM, a Nimbus/Nethermind combo works well.
+
+4+ CPU cores are recommended to deal with spikes in processing.
+
+An SSD is required for storage because the node databases are so IOPS-heavy. An Ethereum mainnet node takes ~ 1.1 TiB
+of storage initially, as of Jan 2024. The on-disk growth pattern differs between execution clients, see
+[resource use](../Usage/ResourceUsage.md).
+
+If you have a 2TB disk, it is expected to last (potentially with execution client pruning) until early 2025.
+Remy wrote a [migration guide to 4TB](https://github.com/eth-educators/ethstaker-guides/blob/main/migrating-to-a-larger-disk.md).
+Also keep an eye on [EIP-4444](https://eips.ethereum.org/EIPS/eip-4444).
+
+Two home server builds that I like and am happy to recommend are below. Both Intel and AMD support IPMI, which means
+they can be managed and power-cycled remotely and need neither a GPU nor monitor. Both support ECC RAM, though the AMD
+option as of Sept 2020 was unable to report ECC errors via IPMI, only OS-level reporting worked.
+
+**Intel**
+
+* mITX: 
+  * SuperMicro X11SCL-IF(-O) (1 NVMe)
+    * Intel i3-9100F or Intel Xeon E-21xx/22xx (i5/7 do not support ECC) - ~ 840 USD with Fractal Node case and NVMe
+  * SuperMicro X12STL-IF(-O) (1 NVMe)
+    * Intel Xeon E-23xx 
+  * SuperMicro X13SCL-IF(-O) (1 NVMe)
+    * Intel Xeon E-24xx
+* uATX:
+  * SuperMicro X11SCL-F(-O) (1 NVMe) or X11SCH-F(-O) (2 NVMe). SCH supports an iGPU
+    * Intel i3-9100(F) or Intel Xeon E-21xx/22xx(G) (i5/7 do not support ECC) - ~ 900 USD with Fractal Node case and
+NVMe
+  * SuperMicro X12STL-F(-O) or X12STH-F(-O) (1 NVMe both). STH supports an iGPU
+    * Intel Xeon E-23xx(G)
+  * SuperMicro X13SCL-F(-O) (1 NVMe) or X13SCH-F(-O) (2 NVMe)
+    * Intel Xeon E-24xx
+* Common components:
+  * 32 GiB of Micron or Samsung DDR4 UDIMM ECC RAM (unbuffered, **not** registered)
+  * [4TB M.2 NVMe SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038)
+
+**AMD**
+
+* mITX:
+  * AsRock Rack X570D4I-2T (1 NVMe)
+* uATX:
+  * AsRock Rack X470D4U or X570D4U (2 NVMe both)
+* Common components:
+  * AMD Ryzen CPU (Zen2/3), but not APU (APUs do not support ECC)
+  * 32 GiB of Micron or Samsung DDR4 UDIMM ECC RAM (unbuffered, **not** registered)
+  * [4TB M.2 NVMe SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038)
+
+* uATX Zen 4:
+  * AsRock Rack B650D4U
+  * AMD Ryzen 7000 CPU (Zen4), but not APU (APUs do not support ECC)
+  * 32 GiB of DDR5 UDIMM ECC RAM (unbuffered, **not** registered)
+  * [4TB M.2 NVMe SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038)
+
+The SuperMicro eStore is one good source of UDIMM ECC, DDR4 and DDR5 both.
+
+Plus, obviously, a case, PSU, case fans. Pick your own. Well-liked options are Node 304 (mITX) and Node 804 (uATX)
+with Seasonic PSUs, but really any quality case that won't cook your components will do. For a small uATX form factor,
+consider Silverstone ML04B.
+
+[Joe's hardware roundup](https://github.com/jclapis/rocketpool.github.io/blob/main/src/guides/local/hardware.md) has
+additional build ideas.
+
+For the SSD, you'll want decent write endurance and good IOPS. You get better sync and prune performance with
+["mainstream" SSDs](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038), that is, SSDs that use TLC
+and have DRAM, not DRAMless or QLC.
+
+You may also consider getting two SSDs and running them in a software mirror (RAID-1) setup, in the OS. That way, data
+loss becomes less likely for the chain databases, reducing potential down time because of hardware issues.
+
+Why ECC? This is a personal preference. The cost difference is minimal,
+and the potential time savings huge. An Ethereum staking full node does not require
+ECC RAM; I maintain it is very nice to have regardless.
+
+With non-ECC RAM, if your RAM goes bad, you will be troubleshooting server
+crashes, and potentially spending days with RAM testing tools.
+
+With ECC RAM, if your RAM goes bad, your OS and, if Intel, IPMI, will alert
+you to corrected (or uncorrected) RAM errors. You'll want to have set up
+email alerts for this. You then buy replacement RAM and schedule downtime.
+No RAM troubleshooting required, you will know whether your RAM is functional or has issues
+because it will report this to you, and correct single-bit errors.
+
+I am so protective of my time these days that I build even my
+home PCs with ECC RAM. You know your own tolerance for troubleshooting
+RAM best.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/ImportKeys.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/ImportKeys.md
new file mode 100644
index 00000000..8813161d
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/ImportKeys.md
@@ -0,0 +1,136 @@
+---
+id: ImportKeys
+title: "Create and import validator keys to the client"
+sidebar_label: Import Validator Keys
+---
+
+You will deposit ETH to the deposit contract, and receive staking rewards on this locked ETH in turn.
+
+> **Vital** [Recommendations.md](../Support/Recommendations.md) has comments on key security. If you haven't
+read these yet, please do so now. You need to know how to guard your keystore password and your seed phrase (mnemonic). **Without the mnemonic, you may be unable to withdraw your funds. You need the seed phrase or your ETH could be gone forever.**
+
+## Create keys
+
+For mainnet, best practice is to create keys using a Linux Live USB and the official [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli). I have a [YouTube walkthrough](https://www.youtube.com/watch?v=oDELXYNSS5w) for this process. Make sure to safeguard your mnemonic and only ever keep it offline! In steel and in a safe is best.
+
+### You want to create keys with Eth Docker
+
+If you are going to use the deposit-cli that is bundled with Eth Docker, please make sure to edit `.env` and that the `COMPOSE_FILE` line contains `:deposit-cli.yml`. You can edit with `nano .env`.
+
+Make sure you're in the project directory, `cd ~/eth-docker` by default.
+
+When creating keys, you can specify an Ethereum address that withdrawals will be paid to. If you have a hardware wallet that withdrawals should go to, this is a good option.
+> Make sure the Ethereum address is correct, you cannot change it after you deposit. You can also remove that parameter, in which  case withdrawals would be done with the mnemonic seed, not against a fixed address
+
+**Do not** set your withdrawal address to an exchange wallet. The funds will not
+be credited, and you will battle support for them.
+
+This command will create the keys to deposit ETH against:
+
+`./ethd cmd run --rm deposit-cli-new --execution_address YOURHARDWAREWALLETADDRESS --uid $(id -u)`
+> Specifying the uid is optional. If this is not done, the generated files will be owned by the user with uid `1000`
+
+Choose the number of validators you wish to create.
+> A validator is synonymous to one 32 Ethereum stake. Multiple validators can be imported to a single validator client.
+
+The created files will be in the directory `.eth/validator_keys` in this project.
+> staking-deposit-cli shows you a different directory, that's because it has a view from inside the container.
+ 
+This is also where you'd place your own keystore files if you already have some for import.
+
+### Test your Seed Phrase
+
+From the project directory:
+
+```
+./ethd cmd run --rm deposit-cli-existing --folder seed_check --execution_address YOURHARDWAREWALLETADDRESS --uid $(id -u)
+```
+> Specifying the uid is optional. If this is not done, the generated files will be owned by the user with uid `1000`
+
+Select your language preference.
+
+Type your mnemonic seed.
+
+Enter the index (key number). 
+> If generated 1 previous validator key file and entered 1 initially, then it is index[0]. So you will enter 0. Hence, you are entering the index from which to start generating the key file from.
+
+Enter how may new validators you wish to run.
+> Enter the number of validators you entered when initially generating the key file.
+> If you are running 1 previous validator and entered 1 initially, then enter 1.
+
+Type any password you like, as you'll throw away the duplicate `keystore-m` files.
+
+Compare the `deposit_data` JSON files to ensure the files are identical.
+```
+diff -s .eth/validator_keys/deposit_data*.json .eth/seed_check/deposit_data*.json
+```
+
+Cleanup duplicate deposit_data.
+```
+rm .eth/seed_check/*
+```
+
+## Decide whether to use web3signer
+
+You have the option of keeping the keys in web3signer, which means you will not need to move them if you switch CL clients. To enable web3signer, `nano .env` and set `WEB3SIGNER=true` and add `:web3signer.yml` to `COMPOSE_FILE`.
+
+Do **not** run keys in both the client directly and web3signer. This can get you slashed. If you wish to switch to web3signer, and already have keys loaded, look at [switching instructions](../Support/SwitchClient.md).
+
+## Using the keymanager API to import keys
+
+**Warning** Import your validator key(s) to only *one* client. If you run them in two locations at once,
+you will be slashed: Forcibly exited and assessed a penalty greater than 1 ETH.
+
+> If you use the [Prysm Web](../Usage/PrysmWeb.md), you can use it
+> or this command-line process to import keys.
+
+### Prysm - create a wallet
+
+Prysm requires a wallet first. Run `./ethd cmd run --rm create-wallet`, which will set up a wallet and a password for it. You can then print the password with `./ethd keys get-prysm-wallet`
+
+### If you used eth2-val-tools
+
+eth2-val-tools is an alternative to staking-deposit-cli/Wagyu Keygen to create keys. If you used eth2-val-tools to generate keys, please copy the generated `keys` and `secrets` directories
+into `.eth/validator_keys`.
+
+### Start the client and import keys
+
+`./ethd up` to start the client and the client's keymanager API
+
+`./ethd keys` to see all options available to you
+
+`./ethd keys import` to import keys and their slashing protection data. This looks in `.eth/validator_keys` for `*keystore*.json` files and optionally `slashing_protection*.json` files, and
+will also import from `keys` and `secrets` directories as created by eth2-val-tools.
+
+If the key JSON files are in another directory, run:
+
+`./ethd keys import --path PATHTOKEYS`
+
+replacing `PATHTOKEYS` with the actual path where they are.
+
+`./ethd keys list` to list all imported keys
+
+> After import, the files in `.eth/validator_keys` can be safely removed from the node,
+> once you have copied them off the node. You'll need the `deposit_data` file to
+> deposit at the launchpad. The `keystore-m` files can be safeguarded in case
+> the node needs to be rebuilt, or deleted and recreated from mnemonic if required.
+> See [Recommendations.md](../Support/Recommendations.md) for some thoughts on key security.
+
+## Importing keys from another validator instance
+
+If you are migrating to Eth Docker from another validator node that uses systemd or some other init system, please see [SwitchClient](../Support/SwitchClient.md) and [Moving](../Support/Moving.md) for advice. Ultimately, you'll likely need to export your keys from your old client and move them to your new node manually, and then use Eth Docker's key management commands to import the keys into clients managed by Eth Docker.
+
+For example, for moving from a system+prysm setup, you'll want to use prysm's [export functionality](https://docs.prylabs.network/docs/advanced/migrating-keys). For other clients, check their official documentation to find out how to export your validator keys. You can then use Eth Docker's key management API to import your keys with `./ethd keys import`.
+
+Please read all of the warnings about slashing and make sure to exercise tons of caution when moving validators to avoid being slashed.
+
+## Deposit at launchpad
+
+**Caution**: You may wish to wait until the consensus and execution client are fully synchronized before you deposit. Check their logs with `./ethd logs -f consensus` and `./ethd logs -f execution`. This safe-guards against the validator being marked offline if your validator is activated before the consensus client syncs.
+
+Once you are ready, you can send eth to the deposit contract by using
+the `.eth/validator_keys/deposit_data-TIMESTAMP.json` file at the [Goerli launchpad](https://goerli.launchpad.ethereum.org/)
+or [Mainnet launchpad](https://launchpad.ethereum.org).
+
+> You can transfer files from your node to a machine with a browser using scp. A graphical
+> tool such as WinSCP will work, or you can use [command line scp](https://linuxize.com/post/how-to-use-scp-command-to-securely-transfer-files/).
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/LinuxSecurity.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/LinuxSecurity.md
new file mode 100644
index 00000000..a131cae5
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/LinuxSecurity.md
@@ -0,0 +1,254 @@
+---
+id: LinuxSecurity
+title: Linux security and setup recommendations
+sidebar_label: Linux Security
+---
+
+## SSH key authentication with Linux
+
+This step is vital if your node's SSH port is reachable via the Internet, for example, because
+it runs on a VPS.
+
+This step is still recommended if the SSH port is not reachable via the Internet.
+
+For security reasons, you want some form of two-factor authentication for SSH login, particularly if SSH
+is exposed to the Internet. These instructions accomplish that by creating an SSH key with passphrase.
+
+To switch to SSH key authentication instead of password authentication, you will start
+on the machine you are logging in from, whether that is Windows 10, MacOS or Linux, and then
+make changes to the server you are logging in to.
+
+On Windows 10, you expect the [OpenSSH client](https://winaero.com/blog/enable-openssh-client-windows-10/)
+to already be installed. If it isn't, follow that link and install it.
+
+From your MacOS/Linux Terminal or Windows Powershell, check whether you have an ssh key. You expect an id_TYPE.pub
+file when running `ls ~/.ssh`.
+
+### Create an SSH key pair
+
+Create a key if you need to, or if you don't have `id_ed25519.pub` but prefer that cipher:<br />
+`ssh-keygen -t ed25519`. Set a strong passphrase for the key.
+> Bonus: On Linux, you can also include a timestamp with your key, like so:<br />
+> `ssh-keygen -t ed25519 -C "$(whoami)@$(hostname)-$(date -I)" -f ~/.ssh/id_ed25519`
+
+### macOS/Linux, copy public key
+
+ If you are on macOS or Linux, you can then copy this new public key to the Linux server:<br />
+`ssh-copy-id USERNAME@HOST`
+
+### Windows 10/11, copy public key
+
+On Windows 10/11, or if that command is not available, output the contents of your public key file
+to terminal and copy, here for `id_ed25519.pub`:<br />
+`cat ~/.ssh/id_ed25519.pub`
+
+On your Linux server, logged in as your non-root user, add this public key to your account:<br />
+```
+mkdir ~/.ssh
+nano ~/.ssh/authorized_keys
+```
+And paste in the public key.
+
+### Test login and turn off password authentication
+
+Test your login. `ssh user@serverIP` from your client's MacOS/Linux Terminal or Windows Powershell should log you in
+directly, prompting for your key passphrase, but not the user password.
+
+If you are still prompted for a password, resolve that first. Your ssh client should show you errors in that case. You
+can run `ssh -v user@serverIP` to get more detailed output on what went wrong.
+
+On Windows 10 in particular, if the ssh client complains about the "wrong permissions" on the `.ssh` directory or
+`.ssh/config` file, go into Explorer, find the `C:\Users\USERNAME\.ssh` directory, edit its Properties->Security, click
+Advanced, then make your user the owner with Full Access, while removing access rights to anyone else, such as SYSTEM
+and Administrators. Check "Replace all child object permissions", and click OK. That should solve the issues the
+OpenSSH client had.
+
+Lastly, once key authentication has been tested, turn off password authentication. On your Linux server:<br />
+`sudo nano /etc/ssh/sshd_config`
+
+Find the line that reads `#PasswordAuthentication yes` and remove the comment character `#` and change it to `PasswordAuthentication no`.
+
+And restart the ssh service, for Ubuntu you'd run `sudo systemctl restart ssh`.
+
+## Set Linux to auto-update
+
+Since this system will be running 24/7 for the better part of 2 years, it's a good idea to have it patch itself.
+Enable [automatic updates](https://libre-software.net/ubuntu-automatic-updates/) and install software so the
+server can [email you](https://caupo.ee/blog/2020/07/05/how-to-install-msmtp-to-debian-10-for-sending-emails-with-gmail/).
+
+For automatic updates, `"only-on-error"` mail reports make sense once you know email reporting is working and
+if you choose automatic reboots, trusting that your services will all come back up on reboot. If you'd like
+to keep a closer eye or schedule reboots yourself, `"on-change"` MailReport is a better choice.
+
+For msmtp, I followed the instructions as-is.
+
+## Time synchronization on Linux
+
+The blockchain requires precise time-keeping. On Ubuntu, systemd-timesyncd is the default to synchronize time,
+and [chrony](https://en.wikipedia.org/wiki/Network_Time_Protocol) is an alternative.
+
+systemd-timesyncd uses a single ntp server as source, and chrony uses several, typically a pool. The default shipping with Ubuntu can get
+out of sync by as much as 600ms before it corrects. My recommendation is to use chrony for better accuracy.
+
+For Ubuntu, install the chrony package. This will automatically remove systemd-timesyncd. Chrony will start automatically.<br />
+`sudo apt update && sudo apt -y install chrony`
+
+Check that chrony is synchronized: Run `chronyc tracking`.
+
+> If you wish to stay with systemd-timesyncd instead, check that `NTP service: active` via 
+> `timedatectl`, and switch it on with `sudo timedatectl set-ntp yes` if it isn't. You can check
+> time sync with `timedatectl timesync-status --all`.
+
+## Firewalling
+
+You'll want to enable a host firewall. You can also forward the P2P ports of your execution and consensus
+clients for faster peer acquisition.
+
+Docker will open execution and consensus client P2P (Peer to Peer) ports and the Grafana port automatically. Please make sure the Grafana port cannot be reached directly. If you need to get to Grafana remotely,
+an [SSH tunnel](https://www.howtogeek.com/168145/how-to-use-ssh-tunneling/) is a good choice.
+
+For a VPS/cloud setup, please take a look at notes on [cloud security](../Support/Cloud.md). You'll want to
+place ufw "in front of" Docker if you are using Grafana or a standalone execution client without a reverse proxy,
+and if your cloud provider does not offer firewall rules for the VPS.
+
+Ports that I mention can be "Open to Internet" can be either forwarded to your node if behind a home router, or allowed in via the VPS firewall.
+
+> Opening the P2P ports to the Internet is optional. It will speed up peer acquisition, which
+> can be helpful. To learn how to forward your ports in a home network, first verify
+> that you are [not behind CGNAT](https://winbuzzer.com/2020/05/29/windows-10-how-to-tell-if-your-isp-uses-carrier-grade-nat-cg-nat-xcxwbt/).
+> Then look at [port-forwarding instructions](https://portforward.com/) for your specific router/firewall.
+
+Forward only the ports that you actually use, depending on your client choices.
+
+- 30303 tcp/udp - Geth/Nethermind/Besu/Erigon execution client P2P. Open to Internet.
+- 9000 tcp/udp - Lighthouse/Teku/Nimbus/Lodestar/Prysm consensus client P2P. Open to Internet.
+- 443 tcp - https:// access to Grafana and Prysm Web UI via traefik. Open to Internet.
+- 22/tcp - SSH. Only open to Internet if you want to access the server remotely. If open to Internet, configure
+  SSH key authentication.
+
+On Ubuntu, the host firewall `ufw` can be used to allow SSH traffic.
+
+Docker bypasses ufw and opens additional ports directly via "iptables" for all ports that are public on the host,
+which means that the P2P ports need not be explicitly listed in ufw.
+
+* Allow SSH in ufw so you can still get to your server, while relying on the default "deny all" rule.
+  * `sudo ufw allow OpenSSH` will allow ssh inbound on the default port. Use your specific port if you changed
+    the port SSH runs on.
+* Check the rule you created and verify that you are allowing SSH, on the port you are running it on.
+  You can **lock yourself out** if you don't allow your SSH port in. `allow OpenSSH` is sufficient
+  for the default SSH port.
+  * `sudo ufw show added`
+* Enable the firewall and see numbered rules once more
+  * `sudo ufw enable`
+  * `sudo ufw status numbered`
+
+> There is one exception to the rule that Docker opens ports automatically: Traffic that targets a port
+> mapped by Docker, where the traffic originates somewhere on the same machine the container runs on,
+> and not from a machine somewhere else, will not be automatically handled by the Docker firewall rules,
+> and will require an explicit ufw rule.
+> Steps to allow for this scenario are in [cloud security](../Support/Cloud.md)
+
+
+## Additional and recommended Linux performance tuning
+
+### noatime
+
+By default, Linux will write a new file timestamp on every read. As you may imagine, this is no bueno for database applications like an Ethereum node.
+
+You can increase the lifetime of your SSD - and incidentally get a small speed boost - by turning this "atime" feature off.
+
+`sudo nano /etc/fstab`
+
+Find the entry for your `/` filesystem, or, if you moved the docker `data-root`, the file system docker lives on.
+
+Find the 4th column. It might read `defaults` right now. Append `,noatime` to it. A full entry might look something like this:
+
+`/dev/disk/by-uuid/33162132-f374-417d-817e-04fdd77e5e11 / ext4 defaults,noatime 0 1`
+
+Don't delete any parameters, just add `,noatime`. And make sure to add that to the 4th column, not anywhere else.
+
+Save, and test with `sudo mount -o remount /`. If that completes without errors, you got it right.
+
+### swappiness
+
+By default, Linux will use swap **a lot**. And, yep you guessed it, that ain't great for database applications like an Ethereum node.
+
+So let's set [swappiness](https://www.howtogeek.com/449691/what-is-swapiness-on-linux-and-how-to-change-it/) to `1`.
+
+`sudo nano /etc/sysctl.conf`
+
+Scroll to the bottom of this file and add
+
+`vm.swappiness=1`
+
+Close and save. Then load the new value with
+
+`sudo sysctl -p`
+
+Alternatively, if you have 32 GiB of RAM or more, you can disable swap entirely with
+
+`sudo swapoff -a`
+
+then edit `/etc/fstab` with `sudo nano /etc/fstab` and comment out the swap volume(s).
+
+### Side channel mitigations - CAUTION
+
+**Here be dragons**
+
+On a VM, VPS, cloud instance, &c, leave this alone. Do not turn off mitigations. They exist for a reason, to keep other processes on the same CPU from reading your secrets.
+
+If however this is a machine you own - baremetal or solo node at home - and the only thing running on here is the Ethereum node, you can turn off side channel mitigations for a small speed boost.
+
+`sudo nano /etc/default/grub`
+
+Find `GRUB_CMDLINE_LINUX` and add `  mitigations=off`
+
+Close and save. `sudo update-grub` and then `sudo reboot`. Provided you got the edit right, the system will come back up, and you can check vulnerability mitigations are now off with `lscpu`
+
+Once more, **don't do this** if the physical machine is shared with VMs or processes you do not control.
+
+## Non-root user on Linux
+
+A standard Ubuntu or Debian install already has a non-root user, that is any user not actually named `root`.
+
+If you are on a VPS that only gives you `root` and do not have a non-root user already, create a non-root user
+with your `USERNAME` of choice to log in as, and give it sudo rights. `sudo` allows you to
+run commands `as root` while logged in as a non-root user.
+
+```
+adduser USERNAME
+```
+
+You will be asked to create a password for the new user, among other things. Then, give the new user
+administrative rights by adding it to the `sudo` group.
+
+```
+usermod -aG sudo USERNAME
+```
+
+Optional: If you used SSH keys to connect to your Ubuntu instance via the `root` user you
+will need to [associate the new user with your public key(s)](#ssh-key-authentication-with-linux).
+
+## Optional: User as part of docker group
+
+Optionally, you may want to avoid needing to type `sudo` every time you run a docker command. In that
+case, you can make your local user part of the `docker` group.
+
+> Please note that a user that is part of the docker group has `root` privileges through docker,
+> even without the use of `sudo`. You may not want this convenience trade-off and choose to
+> explicitly use `sudo` with all docker commands instead.
+
+```
+sudo usermod -aG docker USERNAME
+```
+
+followed by
+
+```
+newgrp docker
+```
+
+## Set up IPMI
+
+This step is highly hardware-dependent. If you went with a server that has IPMI/BMC - out of band management of
+the hardware - then you'll want to configure IPMI to email you on error.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/Networking.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/Networking.md
new file mode 100644
index 00000000..61e861e6
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/Networking.md
@@ -0,0 +1,32 @@
+---
+id: Networking
+title: Networking and port forwarding
+sidebar_label: Network configuration
+---
+
+## Static IP
+
+With a VPS, you have a static IP by default. In your home network, that is typically not the case.
+
+You'll want a static IP address for your server, one that doesn't change. This allows easier
+port-forwarding for your Ethereum client peering, and easier management and remote access for you:
+You do not need to find a changing server address. You can do set an unchanging IP address a few
+different ways.
+
+- You can configure your router to use a [DHCP reservation](https://homenetworkadmin.com/dhcp-reservation/).
+How to do this depends on your router.
+- You could instead choose an IP address *outside* your DHCP range and [configure it as a static IP](https://linuxhint.com/setup_static_ip_address_ubuntu/).
+
+In Ubuntu Desktop this is done through Network Manager from the UI, and in Ubuntu Server you'll handle it
+from CLI via netplan. Check your router configuration to see where your DHCP range is, and what
+values to use for default gateway and DNS.
+
+## Port forwarding
+
+By default, the clients use UDP/TCP 30303 and UDP/TCP 9000 as their P2P, "Peer to Peer", ports. These should be "open to Internet". If you're on a home network, set up [port forwarding](https://portforward.com/) on your router for these. If you are behind CGNAT from your ISP, this will not work. To verify, look at the WAN IP of your router and at https://www.whatismyip.com/. If they match, you are not behind CGNAT. If they don't, you are. Ask your ISP for a static IP address to resolve this.
+
+## Firewalling
+
+In a home network, nothing special is required for firewalling. You can use UFW and allow only OpenSSH, if you like.
+
+If you are with a cloud provider and they do not offer a firewall, **and** you chose to use Grafana for monitoring, you'll want to make sure Grafana is firewalled so it is only reachable via SSH tunnel or traefik. Please see [Cloud Security](../Support/Cloud.md), how to set up a [secure proxy](../Usage/ReverseProxy.md) and this [Youtube walkthrough](https://www.youtube.com/watch?v=F2dL7j-sEHY&t=4s).
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/Prerequisites.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/Prerequisites.md
new file mode 100644
index 00000000..b6119a6c
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/Prerequisites.md
@@ -0,0 +1,226 @@
+---
+id: Prerequisites
+title: "Step 1: Install Prerequisites."
+sidebar_label: Prerequisites
+---
+
+Eth Docker relies on Docker and Docker Compose, and git for initial install and updates. It has been tested on Linux,
+and is expected to work on MacOS.
+
+> The following prerequisites will be installed on the Linux server you will run your node on. The machine you use to
+connect *to* the Linux server only requires an SSH client.
+
+## Ubuntu Prerequisites
+
+> Ubuntu can be installed with the Docker snap package, which can cause issues including complete data loss on upgrade.
+We highly recommend removing this via `sudo snap remove --purge docker`. Note this action will delete all data kept
+in Docker. If you are running the snap Docker package and have data you need to keep, please ask for help in the
+ethstaker Discord.
+
+Eth Docker has been tested on Ubuntu 24.04 "Mantic Minotaur", Ubuntu 22.04 "Jammy Jellyfish" and Ubuntu 20.04
+"Focal Fossa". An [LTS](https://wiki.ubuntu.com/Releases), Long Term Support, version of Ubuntu is recommended, either
+Ubuntu Server or Ubuntu Desktop. If installing Ubuntu Server, make doubly sure to extend the "lv", logical volume, to
+use your entire disk during the install.
+
+### Automatic installation
+
+Clone the project: `git clone https://github.com/eth-educators/eth-docker.git && cd eth-docker`
+
+Run `./ethd install` and follow prompts
+
+### Manual installation
+
+Install docker-ce:
+
+```
+sudo apt-get update
+sudo apt-get -y install ca-certificates curl gnupg lsb-release whiptail
+sudo mkdir -p /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
+sudo echo \
+  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
+  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
+```
+
+You know it was successful when you saw messages scrolling past that install Docker and Docker Compose.
+
+If you like, you can also add a docker-compose alias, replacing `MYUSERNAME` with your actual user name:
+`echo 'alias docker-compose="docker compose"' >>/home/MYUSERNAME/.profile`
+
+## Debian Prerequisites
+
+Eth Docker has been tested on Debian 11 "Bullseye" and Debian 12 "Bookworm".
+
+### Automatic installation
+
+Clone the project: `git clone https://github.com/eth-educators/eth-docker.git && cd eth-docker`
+
+Run `./ethd install` and follow prompts
+
+### Manual installation
+
+Install docker-ce:
+
+```
+sudo apt-get update
+sudo apt-get -y install ca-certificates curl gnupg lsb-release whiptail
+sudo mkdir -p /etc/apt/keyrings
+sudo curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
+sudo echo \
+  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
+  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
+sudo apt-get update
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
+```
+
+You know it was successful when you saw messages scrolling past that install docker and docker compose.
+
+If you like, you can also add a docker-compose alias, replacing `MYUSERNAME` with your actual user name:
+`echo 'alias docker-compose="docker compose"' >>/home/MYUSERNAME/.profile`
+
+## Generic Linux
+
+Other distributions are expected to work as long as they support git, Docker, and Docker Compose.
+
+On Linux, Docker Compose runs as root by default. The individual containers do not, they run as local users inside the
+containers. "Rootless mode" is expected to work for docker with this project, as it does not use AppArmor.
+
+## Change Docker storage location
+
+Taken from the [RocketPool docs](https://docs.rocketpool.net/guides/node/docker.html#configuring-docker-s-storage-location)
+
+By default, Docker will store all of its container data on your operating system's drive. In some cases, this is
+**not** what you want. For example, you may have a small boot drive and a second larger SSD for the chain data.
+
+> If you have just one drive and are good with the default behavior, don't make these adjustments
+
+To change the Docker volume location, create a new file called /etc/docker/daemon.json as the root user:
+
+```
+sudo nano /etc/docker/daemon.json
+```
+
+Add this as the contents:
+
+```
+{
+    "data-root": "<your external mount point>/docker"
+}
+```
+
+where `<your external mount point>` is the directory that your other drive is mounted to.
+
+Next, make the folder:
+
+```
+sudo mkdir -p <your external mount point>/docker
+```
+
+If you already have existing volumes that you want to move, stop Docker and move them over:
+
+```
+sudo systemctl stop docker
+sudo cp -rp /var/lib/docker <your external mount point>/
+```
+
+Now, restart the Docker daemon so it picks up on the changes:
+
+```
+sudo systemctl restart docker
+```
+
+After that, Docker will store its data on your desired disk.
+
+## Switching from docker.io to docker-ce
+
+If you are currently running Canonical's docker.io and you'd like to switch to docker-ce, the "Community Edition"
+released by Docker, Inc., this is how.
+
+You do not need to stop running containers manually, and they will be back up and running after. All volumes and other
+data kept in Docker will stay intact.
+
+If you came here because of a nag message, you can switch out docker.io for docker-ce, or you can narrowly just upgrade
+Compose to V2, and remove Compose V1. In that case, stop before "Prepare docker-ce repo".
+
+If you want to keep docker.io, and add the Compose V2 plugin, you can do so by:
+
+`sudo apt-mark manual docker.io && sudo apt-get remove --autoremove -y docker-compose && sudo apt-get install -y docker-compose-v2`
+
+**Only** if you wish to replace docker.io with docker-ce, continue below.
+
+Prepare docker-ce repo:
+
+```
+sudo apt-get update
+sudo apt-get install -y ca-certificates curl gnupg lsb-release
+
+sudo mkdir -p /etc/apt/keyrings
+curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
+https://download.docker.com/linux/ubuntu  $(lsb_release -cs) stable" \
+| sudo tee /etc/apt/sources.list.d/docker.list >/dev/null
+ 
+sudo apt-get update
+```
+
+Remove docker.io:
+
+```
+sudo apt-get remove --autoremove -y docker.io containerd runc docker-compose docker-compose-v2
+```
+
+Reboot - yes this is mandatory:
+
+```
+sudo reboot
+```
+
+Install docker-ce:
+
+```
+sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin docker-buildx-plugin
+```
+
+Verify that all containers started automatically:
+```
+sudo docker ps
+```
+
+If you like, you can also add a docker-compose alias, replacing `MYUSERNAME` with your actual user name:
+`echo 'alias docker-compose="docker compose"' >>/home/MYUSERNAME/.profile`
+
+## rootless Docker
+
+Eth Docker works with [rootless Docker](https://docs.docker.com/engine/security/rootless/).
+
+If using Grafana, use `grafana-rootless.yml` instead of `grafana.yml`. This omits node-exporter, cadvisor, promtail and
+Loki.
+
+If using traefik, either change its ports in `.env` to be above `1024`, or
+[expose privileged ports](https://docs.docker.com/engine/security/rootless/#exposing-privileged-ports).
+
+## macOS Prerequisites
+
+> The following prerequisites apply if you are going to use macOS as a server to run an Ethereum staking full node. If
+you use macOS to connect *to* a node server, all you need is an SSH client.
+
+- Install [Docker Desktop](https://www.docker.com/products/docker-desktop) and allocate 16+ GiB of RAM and 3TB or so
+of storage space to it, in Preferences->Resources->Advanced.
+- Install prerequisites via homebrew: `brew install coreutils newt bash`
+- You may need to log out and back into your terminal session to have the right version of bash. Try `bash --version`
+and verify it's 5.x or higher.
+- Verify git is installed with `git --version`. It will show a Desktop prompt to install it if it isn't.
+
+> Docker Desktop on macOS has its ideosyncrasies. An arguable easier path could be to keep macOS just for firmware
+updates and [dual-boot into Debian Linux](https://wiki.debian.org/InstallingDebianOn/Apple).
+
+## Windows 11
+
+It is technically possible to run Eth Docker on [Windows 11](../Support/Windows.md).
+
+However, the challenges inherent in running on Windows 11 are easier to solve when using the Windows-native versions of
+the clients, rather than wrapping Docker around them.
+
+Windows 10/11 is fine as an SSH client to connect *to* your Linux server.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/PrysmWeb.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/PrysmWeb.md
new file mode 100644
index 00000000..5b531558
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/PrysmWeb.md
@@ -0,0 +1,83 @@
+---
+id: PrysmWeb
+title:  Web UI
+sidebar_label: Web UI
+---
+
+## Lighthouse
+
+The Lighthouse Siren Web UI uses https with self-signed certificates. To use it, add `siren.yml` to `COMPOSE_FILE` in
+`.env`, and if you are not going to use traefik, add `siren-shared.yml` as well. It is then reachable on port `2443`
+by default. The port can be adjusted in `.env`.
+
+## Prysm
+
+The Prysm Web UI is insecure http, which means an [SSH tunnel](https://www.howtogeek.com/168145/how-to-use-ssh-tunneling/)
+should be used to access it if your node is on a cloud VPS.
+
+If you wish to expose the Web UI across the network, which also exposes the key management UI, you can add `prysm-web-shared.yml` to your `COMPOSE_FILE` in `.env`.
+
+If you wish to only expose the Web UI to `localhost` and then use either a browser on the host or an SSH tunnel, you can add `validator-keyapi-localport.yml` to `COMPOSE_FILE` in `.env`.
+
+## Prepare the validator client
+
+The Web UI can be used to import keys and create a wallet, but we also need the password for this
+wallet while starting the validator. To get around this chicken-and-egg problem, you can run
+`./ethd cmd run --rm create-wallet` now and choose the wallet password you will use during
+the Web UI Wallet Creation.
+
+> This password needs to be at least 8 characters long and contain both a number and a special
+> character. The script that stores the password here does not enforce that, but the Web UI does.
+
+Either way, once you are done, run `./ethd up` to start the Prysm consensus client
+and validator.
+
+## Connect to the Web UI
+
+You need the Web UI secret first. It is shown during startup in the validator client log. You can also run `./ethd keys get-api-token` to get it.
+
+The first time you connect to the Web UI, you'll want to use `http://IP:7500/initialize?token=THETOKEN`, replacing `IP` and `THETOKEN` with the actual IP address and access token.
+
+If your node is on a local, protected LAN, you can access the Web UI on a browser from any machine on your network via the node's IP address, if you use `prysm-web-shared.yml`.
+
+If the node is running on a cloud VPS, you'll want to use `validator-keyapi-localhost.yml` to restrict access to just `localhost`, then open an SSH connection and tunnel the port used by the Web UI.
+
+Example ssh command:
+```
+ssh -L 7500:<host>:7500 <user>@<host>
+```
+
+where `<host>` is the name or IP address of the node.
+
+Placing this into an alias or shell script can make life easier.
+
+Once the SSH tunnel is open, in a browser, open `http://127.0.0.1:7500`. You'll be prompted for a web password,
+which doesn't yet exist, and there may be an option to "Create a Wallet" if you did not do so from
+command line.
+
+> Note this is insecure http. The SSH tunnel encrypts the traffic.
+
+# Import keys
+
+Assuming you have some `keystore-m` JSON files from `./ethd cmd run --rm deposit-cli-new --execution_address YOURHARDWAREWALLETADDRESS` or some other way of creating Launchpad compatible keys, click on "Create a Wallet".
+
+> These files are in `.eth/validator_keys` if you used the `deposit-cli` workflow. You'll want to move them to the machine you are running the browser on.
+
+Choose to "Import Keystores". Select the `keystore-m` file(s), provide the password to the keystore, choose whether to import slashing protection data, and Continue.
+
+Set the wallet password.  If you chose to store the wallet password with the validator in a previous step,
+make sure it matches here: This is the step where you actually create the wallet with that password.
+
+Continue and you will find yourself inside the Web UI, which will show you the consensus client syncing. Once sync is
+complete, you will also see validator information.
+
+# Optional: Verify that wallet password was stored correctly
+
+If you chose to start the validator with a stored wallet password, verify that it was stored correctly by running these commands, one at a time:
+
+```
+./ethd restart
+./ethd logs -f validator
+```
+
+You'll need to navigate to the root of the Web UI and log in again after the restart.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/QuickStart.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/QuickStart.md
new file mode 100644
index 00000000..dcae811a
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/QuickStart.md
@@ -0,0 +1,65 @@
+---
+id: QuickStart
+title:  Eth Docker QuickStart
+sidebar_label: QuickStart
+---
+
+Warnings about the dangers of running Ethereum staking full nodes are in [Recommendations.md](../Support/Recommendations.md).  
+In particular, you must be sure to secure your seed phrase, the mnemonic. You need it to recreate keys, and
+to set a withdrawal address, if you didn't already do so during key creation.
+
+## Hardware, resource use
+
+Take a look at some [build ideas](../Usage/Hardware.md) and consider clients' [resource requirements](../Usage/ResourceUsage.md)
+
+## Eth Docker QuickStart
+
+For a rapid start, have Ubuntu or Debian Linux installed, and then follow these steps. This has been tested on Ubuntu
+20.04/22.04 and Debian 11/12. 
+
+Download Eth Docker
+
+`cd ~ && git clone https://github.com/eth-educators/eth-docker.git && cd eth-docker`
+
+Install pre-requisites such as Docker
+
+`./ethd install`
+
+Configure Eth Docker - have an Ethereum address handy where you want Execution Layer rewards to go
+
+`./ethd config`
+
+Start Eth Docker
+
+`./ethd up`
+
+The same script can also be used to stop, start and update the node. Run `./ethd` for a help screen.
+
+> Note that Docker will restart running clients automatically after a reboot. They will remain stopped if you stopped
+them with `./ethd stop` or equivalent Docker commands.
+
+All your settings are in `.env` and can be viewed and edited with `nano .env`. You can also re-run `./ethd config` at
+any time.
+
+## Next steps
+
+If you are going to run a validating node, [create and import keys](../Usage/ImportKeys.md). 
+
+Forward the [P2P ports](../Usage/Networking.md) that the clients use.
+
+Consider your [Linux security](../Usage/LinuxSecurity.md)
+
+Deposit your 32 ETH using the official [Staking Launchpad](https://launchpad.ethereum.org/en/).
+
+## Advanced use
+
+macOS requires [manual installation](../Usage/Prerequisites.md) of Docker Desktop. 
+
+Explore the sidebar for advanced options. In particular, you can [integrate with RocketPool](../Support/Rocketpool.md),
+run an [SSV operator node](../Support/SSV.md), or run an [RPC node](../Usage/ClientSetup.md) with either locally
+shared RPC/WS ports or these ports [secured by Traefik and https](../Usage/ReverseProxy.md).
+
+## Additional resources
+
+[Youtube Channel](https://www.youtube.com/channel/UCS5mP-iWYxOCBVSVugPYUhQ)  
+[Security Best Practices](https://www.coincashew.com/coins/overview-eth/archived-guides/guide-or-how-to-setup-a-validator-on-eth2-mainnet/part-i-installation/guide-or-security-best-practices-for-a-eth2-validator-beaconchain-node)
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/ResourceUsage.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/ResourceUsage.md
new file mode 100644
index 00000000..74cfef49
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/ResourceUsage.md
@@ -0,0 +1,114 @@
+---
+id: ResourceUsage
+title:  Client Resource Usage
+sidebar_label: Client Resource Usage
+---
+
+# Consensus Clients
+
+| Client | Version | Date | DB Size  |  RAM | Notes |
+|--------|---------|----  |----------|------|-------|
+| Teku   | 23.12.1  | Jan 2024 | ~130 GiB | ~10 GiB |
+| Lighthouse | 4.5.0  | Jan 2024 | ~130 GiB | ~5 GiB |
+| Nimbus | 24.1.1 | Jan 2024 | ~170 GiB | ~2 to 3 GiB |
+| Prysm | 4.1.1 | Jan 2024 | ~130 GiB | ~5 GiB |
+| Lodestar | 1.13.0 | Jan 2024 | ~130 GiB | ~8 GiB |
+
+Notes on disk usage
+- Teku, Nimbus and Grandine continuously prune
+- Lighthouse, Lodestar and Prysm can be resynced in minutes to bring space usage back down, with `./ethd resync-consensus`
+- Lighthouse is working on tree states to continuously prune
+
+# Execution clients
+
+For reference, here are disk, RAM and CPU requirements, as well as mainnet initial synchronization times, for different Ethereum execution clients.
+
+## Disk, RAM, CPU requirements
+
+SSD, RAM and CPU use is after initial sync, when keeping up with head. 100% CPU is one core.
+
+Please pay attention to the Version and Date. These are snapshots in time of client behavior. Initial state size increases over time, and execution clients are always working on improving their storage engines.
+
+| Client | Version | Date | DB Size  | DB Growth | RAM | Notes |
+|--------|---------|----  |----------|-----------|-----|-------|
+| Geth   | 1.13.8 | Jan 2024 | ~1.1 TiB | ~7-8 GiB / week | ~ 8 GiB | with PBSS |
+| Nethermind | 1.27.0 | Jun 2024 | ~800 GiB | ~11 GiB / week | ~ 7 GiB | With HalfPath, can automatic online prune at ~350 GiB free |
+| Besu | v23.10.3-hotfix | Jan 2024 | ~1.1 TiB | ~7-8 GiB / week | ~ 10 GiB | with Bonsai and trie log limit |
+| Reth | alpha.13 | Jan 2024 | ~1.1 TiB | ~ 3.5 GiB / week | ~ 9 GiB | throws away all logs except deposit contract, and so grows more slowly |
+| Erigon | 2.56.1 | Jan 2024 | ~1.7 TiB | ~7-8 GiB / week | See comment | Erigon will have the OS use all available RAM as a DB cache during post-sync operation, but this RAM is free to be used by other programs as needed. During sync, it may run out of memory on machines with less than 32 GiB |
+
+Notes on disk usage
+- Reth, Besu, Geth and Erigon continously prune
+- Nethermind - DB size can be reduced when it grew too large, by [online prune](../Support/GethPrune.md). Keep an eye
+on [Paprika](https://github.com/NethermindEth/nethermind/pull/7157) and
+[Path](https://github.com/NethermindEth/nethermind/pull/6499) work
+- Erigon does not compress its DB, leaving that to the filesystem
+
+## Test Systems
+
+IOPS is random read-write IOPS [measured by fio with "typical" DB parameters](https://arstech.net/how-to-measure-disk-performance-iops-with-fio-in-linux/), 150G file, without other processes running.
+
+Specifically `fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=150G --readwrite=randrw --rwmixread=75`, then `rm test` to get rid of the 150G test file. If the test shows it'd take hours to complete, feel free to cut it short once the IOPS display for the test looks steady.
+
+150G was chosen to "break through" any caching strategems the SSD uses for bursty writes. Execution clients write steadily, and the performance of an SSD under heavy write is more important than its performance with bursty writes.
+
+Read and write latencies are measured with `sudo iostat -mdx 240 2` during Geth sync, look at `r_await` and `w_await` of the second output block.
+
+Servers have been configured with [noatime](https://www.howtoforge.com/reducing-disk-io-by-mounting-partitions-with-noatime) and [no swap](https://www.geeksforgeeks.org/how-to-permanently-disable-swap-in-linux/) to improve available IOPS.
+
+
+| Name                 | RAM    | SSD Size | CPU        | r/w IOPS | r/w latency | Notes |
+|----------------------|--------|----------|------------|------|-------|--------|
+| Homebrew Xeon ZFS zvol | 32 GiB | 1.2 TiB | Intel Quad | 3.5k/1k | | Intel SATA SSD, 16k recordsize, stripe, xfs; fio with --bs=16k |
+| Homebrew Xeon ZFS dataset | 32 GiB | 1.2 TiB | Intel Quad | 1.2k/500 | | Intel SATA SSD, 16k recordsize, stripe, xfs; 16G Optane SLOG |
+| Dell R420 w/ HBA     | 32 GiB | 1 TB | Dual Intel Octo | 35.9k/11k | Xeon E5-2450 |
+| [Contabo](https://contabo.com) Storage VPS L  | 16 GiB | 1600 GiB | AMD EPYC Hexa  | 3k/1k | |  |
+| [Netcup](https://netcup.eu) VPS 3000 G9   | 24 GiB | 600 GiB  | AMD Hexa | 11.2k/3.7k | 2.25/6 ms | |
+| Netcup RS 8000 G9.5 | 64 GiB | 2 TB | AMD EPYC 7702 | 15.6k/5k | 3.4/1.5 ms | |
+| [OVH](https://ovhcloud.com/) Baremetal NVMe   | 32 GiB | 1.9 TB  | Intel Hexa | 177k/59k | 0.08/3.5 ms | |
+| [AWS](https://aws.amazon.com/) io1 w/ 10K IOPS  | 8 GiB  | NA      | Intel Dual | 7.6k/2.5k | | t2.large, could not sync Geth. Note t2 throttles CPU |
+| AWS gp3 w/ 16K IOPS  | 16 GiB | NA      | Intel Quad | 12.2k/4.1k | | m6i.xlarge |
+
+## Initial sync times
+
+Please pay attention to the Version and Date. These are snapshots in time of client behavior.
+
+NB: All execution clients need to [download state](https://github.com/ethereum/go-ethereum/issues/20938#issuecomment-616402016) after getting blocks. If state isn't "in" yet, your sync is not done. This is a heavily disk IOPS dependent operation, which is why HDD cannot be used for a node.
+
+For Nethermind, seeing "branches" percentage reset to "0.00%" after state root changes with "Setting sync state root to" is normal and expected. With sufficient IOPS, the node will "catch up" and get in sync.
+
+For Geth, you will see "State heal in progress" after initial sync, which will persist for a few hours if IOPS are low-ish.
+
+This should complete in under 4 hours. If it does not, or even goes on for a week+, you do not have sufficient IOPS for Geth to "catch up" with state.
+
+Cache size default in all tests.
+
+| Client | Version | Date | Test System | Time Taken |  Notes |
+|--------|---------|------|-------------|------------|--------|
+| Geth   | 1.13.0  | August 2023 | OVH Baremetal NVMe | ~ 6 hours | |
+| Nethermind | 1.24.0| Jan 2024 | OVH Baremetal NVMe | ~ 5 hours | Ready to attest after ~ 1 hour |
+| Besu | v23.10.4-dev | December 2023 | OVH Baremetal NVMe | ~ 16 hours | With X_SNAP sync |
+| Erigon | 2.48.1 | August 2023 | OVH Baremetal NVMe | ~ 9 days | |
+| Reth  | beta.1 | March 2024 | OVH Baremetal NVMe | ~ 2 days 16 hours | |
+
+## Getting better IOPS
+
+Ethereum execution layer clients need a decent amount of IOPS. HDD will not be sufficient.
+
+For cloud providers, here are some results for syncing Geth.
+- AWS, gp2 or gp3 with provisioned IOPS have both been tested successfully.
+- Linode block storage, make sure to get NVMe-backed storage.
+- Netcup is sufficient as of late 2021.
+- There are reports that Digital Ocean block storage is too slow, as of late 2021.
+- Strato V-Server is too slow as of late 2021.
+
+Dedicated servers with SATA or NVMe SSD will always have sufficient IOPS. Do avoid hardware RAID though, see below.
+OVH Advance line is a well-liked dedicated option; Linode or Strato or any other provider will work as well.
+
+For own hardware, we've seen three causes of low IOPS:
+- DRAMless or QLC SSD. Choose a ["mainstream" SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038)
+with TLC and DRAM. Enterprise / data center SSDs will always work great; consumer SSDs vary.
+- Overheating of the SSD. Check `smartctl -x`. You want the SSD to be at ~ 40-50 degrees Celsius, so it does not
+throttle.
+- Hardware RAID, no TRIM support. [Flash the controller](https://gist.github.com/yorickdowne/fd36009c19fdbee0337bffc0d5ad8284)
+to HBA and use software RAID.
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/ReverseProxy.md b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/ReverseProxy.md
new file mode 100644
index 00000000..bb253136
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/current/Usage/ReverseProxy.md
@@ -0,0 +1,144 @@
+---
+id: ReverseProxy
+title: "Additional security: Secure Web Proxy"
+sidebar_label: Secure Web Proxy
+---
+
+You can use the "[traefik](https://traefik.io/)" secure web proxy to get to the Grafana Dashboard and Prysm Web UI via
+https:// instead of insecure http://. It can also be used to encrypt the RPC and WS ports of your execution client, so
+they are reachable via https:// and wss:// respectively. In addition, it can be used to separate the consensus client
+and validator client to different machines.
+
+You will require a domain name for this to work. Where you buy it is up to you.
+
+As a 450m overview, traefik will be reachable via port 443 / https from the Internet (configurable, could be 8443 if
+you prefer). All browsing attempts to it will be checked by traefik for their hostname, and it steers traffic to the
+right container thereby: To Grafana, to Prysm Web UI, and to the execution client. Grafana, Prysm web UI, Siren,
+RPC and WS ports and for `cl-only.yml` REST ports will be reachable on their configured hostname if traefik
+is configured. If you want Grafana and not RPC, for example, simply do not create a DNS (CNAME) entry for RPC.
+
+For example, say I have a domain `example.com`, left the `_HOST` and port settings in `.env` at default, and am running
+Prysm with Grafana and Web UI.  `https://grafana.example.com/` will get me to my Grafana dashboard, and
+`https://prysm.example.com` to my Prysm Web UI.
+
+## Cloudflare for DNS management
+
+With this option, CloudFlare will provide DNS management as well as DDoS protection. Traefik uses CloudFlare to issue a
+Let's Encrypt certificate for your domain. This also automatically updates the IP address of the domain, which is
+useful if you are on a dynamic address, such as domestic Internet. This only works for a subdomain such as
+`grafana.example.com`, not for the domain itself like `example.com`.
+
+You'll add `traefik-cf.yml` to your `COMPOSE_FILE` in `.env`, for example:
+`lighthouse.yml:geth.yml:grafana.yml:traefik-cf.yml`
+
+Create a (free) CloudFlare account and set up your domain, which will require pointing nameservers for your domain to
+Cloudflare's servers. How this is done depends on your domain registrar.
+
+You will need a "scoped API token" from CloudFlare's [API page](https://dash.cloudflare.com/profile/api-tokens). Create
+a token with `Zone.DNS:Edit`, `Zone.Zone:Read` and `Zone.Zone Settings:Read` permissions, for all zones. Make a note of
+the token secret, it will only be shown to you once.
+
+If you want to be [more specific](https://go-acme.github.io/lego/dns/cloudflare/), you can create two scoped API
+tokens: One with `Zone.DNS:Edit` for just the domain you wish to manage, and one with `Zone.Zone:Read` and
+`Zone.Zone Settings:Read` for all zones.
+
+With that, in the `.env` file:
+- Set `DOMAIN` to your domain.
+- Set `ACME_EMAIL` to the email address Let's Encrypt will use to communicate with you.
+- Set `CF_ZONE_ID` to the Zone ID of the domain, visible in the Overview page of your domain, on the right-hand side
+- Set `CF_DNS_API_TOKEN` to the API token with `Edit` rights you just created
+under "API".
+- Optionally set `CF_ZONE_API_TOKEN` to the API token with `Read` rights, only if you created split permissions.
+- Set `DDNS_SUBDOMAIN` to the specific A/AAAA record you want to see created. If you want to update the domain
+itself, make this @.
+- Set `DDNS_PROXY` to `false` if you do not want CloudFlare to proxy traffic to the subdomain
+
+### CNAMEs and proxy settings
+
+You need CNAMEs or A records for the services you make available. Assuming you have set the subdomain `grafana` with
+the IP address of your host, and keeping the default names in `.env`, set the CNAMEs for only the services you use:
+
+- `grafana` is automatically created, proxied, for the Grafana dashboard
+- `prysm` CNAME to `grafana.example.com`, proxied, for the Prysm Web UI
+- `el` CNAME to `grafana.example.com`, DNS only, for the execution client RPC https:// port
+- `elws` CNAME to `grafana.example.com`, DNS only, for the execution client WS wss:// port
+
+If you are using CloudFlare to proxy Grafana / Prysm web, you'll also want to set these:
+
+- SSL/TLS, Overview: "Full" or "Full (strict)" encryption mode
+- SSL/TLS, Edge Certificates: Always use HTTPS on, Minimum TLS version to 1.2, Opportunistic Encryption on, TLS 1.3 on,
+Automatic HTTPS Rewrites on, Certificate Transparency Monitoring on
+
+## AWS for DNS management
+
+With this option, AWS Route53 will provide DNS management, there is no DDoS protection built in. Traefik uses
+Route53 to issue a Let's Encrypt certificate for your domain. It does not create an A record for you, that is left
+up to you.
+
+You'll add `traefik-aws.yml` to your `COMPOSE_FILE` in `.env`, for example:
+`lighthouse.yml:geth.yml:grafana.yml:traefik-aws.yml`
+
+This setup assumes that you already have an [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+named user profile in `~/.aws` on the node itself. If not, [please create one](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html).
+Be sure to specify a default region during `aws configure`. This is not optional.
+
+The IAM user will need to have the AWS-managed `AmazonRoute53ReadOnlyAcces`, `AmazonRoute53AutoNamingFullAccess` and
+`AmazonRoute53DomainsFullAccess` policies [attached to it](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
+
+With that, in the `.env` file:
+- Set `DOMAIN` to your domain.
+- Set `ACME_EMAIL` to the email address Let's Encrypt will use to communicate with you.
+- Set `AWS_PROFILE` to the profile you want to use. This is the profile name as shown in `~/.aws/config` and
+`~/.aws/credentials`, e.g. `default` or whichever name you gave it, *not* the access key id. The profile
+**must** contain a region.
+- Set `AWS_HOSTED_ZONE_ID` to the Route53 zone you are going to use
+
+### A records and CNAMEs
+
+Assuming you use the default names in `.env`:
+
+- An A record for your first service such as `grafana.example.com`, or on the domain itself `example.com` to use for
+CNAMEs. The A record will be the IP address of your node
+- Optionally, additional CNAMEs for `grafana`, `prysm`, `el` and `elws`, depending on which services you want to
+reverse-proxy on the node
+
+## Traefik common settings
+
+Optionally, you can change the names that services are reachable under, and adjust CNAMEs to match. These are the
+`_HOST` variables.
+
+## Separating consensus client and validator client
+
+Eth Docker supports separating the consensus client and validator client on different machines, with TLS encryption
+between them.
+
+### Consensus client machine
+
+On the machine that runs the consensus client, you'll need `CLIENT-cl-only.yml` with `CLIENT` one of `teku`,
+`lighthouse`, `nimbus`, `lodestar` or `prysm`, as well as one of the `traefik-XXX.yml` files. For example, with
+Lighthouse and CloudFlare: `COMPOSE_FILE=lighthouse-cl-only.yml:traefik-cf.yml`.
+
+Traefik needs to be configured as per the above. Make sure you have a DNS entry for the machine, something like
+`cl.example.com` if `CL_HOST` is at default and your `DOMAIN` is `example.com`. If you use CloudFlare, you can proxy
+this entry.
+
+Make sure port 443/tcp is reachable from the outside. Note this is the CL REST port even for Prysm, what Prysm calls
+the "grpc-gateway". The Prysm GRPC port 4000 is not available externally.
+
+In both cases it is prudent to restrict communications to just the IP address of the validator client machine.
+
+### Validator client machine
+
+On the machine that runs the validator client, you'll need `CLIENT-vc-only.yml` with `CLIENT` one of `teku`,
+`lighthouse`, `nimbus` or `lodestar`. For example, for Lighthouse: `COMPOSE_FILE=lighthouse-vc-only.yml`
+
+VCs should be interoperable with any CL. Teku and Lighthouse teams test this mutually; for other combinations you'll
+want to do some testing yourself.
+
+The `CL_NODE` variable needs to be set to point to the consensus client.
+
+For Teku and Lighthouse: `CL_NODE=https://cl.example.com` , assuming you left the `CL_HOST` variable at default on the
+consensus client, the Traefik port at default, and your domain is `example.com`.  
+Lighthouse and Teku also support failover nodes, which means you could configure
+`CL_NODE=https://cl.example.com,https://cl2.example.com`
+
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/static/.nojekyll b/website/i18n/fr/docusaurus-plugin-content-docs/static/.nojekyll
new file mode 100644
index 00000000..e69de29b
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/static/CNAME b/website/i18n/fr/docusaurus-plugin-content-docs/static/CNAME
new file mode 100644
index 00000000..5d3b9b49
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/static/CNAME
@@ -0,0 +1 @@
+ethdocker.com
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/static/css/custom.css b/website/i18n/fr/docusaurus-plugin-content-docs/static/css/custom.css
new file mode 100755
index 00000000..209d5ae5
--- /dev/null
+++ b/website/i18n/fr/docusaurus-plugin-content-docs/static/css/custom.css
@@ -0,0 +1,69 @@
+/**
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+/* General elements */
+
+a {
+	color: #ff30a0;
+}
+
+/* Header elements */
+
+.mainContainer .wrapper .post .postHeaderTitle {
+    margin-top: 10px;
+}
+.toc .toggleNav ul li a {
+    font-size: 15px;
+    padding: 2px 0;
+
+}
+.fixedHeaderContainer {
+    border-bottom: 3px solid #ff30a0;
+}
+.toc .toggleNav .navGroup .navGroupCategoryTitle {
+    font-size: 17px;
+    color: #22292f;
+}
+
+/* Sidebar elements */
+
+.onPageNav a:hover {
+    color: #ff30a0;
+}
+.toc .toggleNav ul li a:hover {
+    color: #ff30a0;
+
+}
+.toc .toggleNav ul li.navListItemActive a {
+    color: #22292f;
+    font-weight: 600;
+}
+
+@media (max-width: 736px) {
+    .nav-footer {
+        text-align: center;
+        margin:auto;
+    }
+
+    .nav-home {
+        margin:auto !important; 
+    }
+
+}
+
+@media only screen and (min-device-width: 360px) and (max-device-width: 736px) {
+}
+
+@media only screen and (min-width: 1024px) {
+}
+
+@media only screen and (max-width: 1023px) {
+}
+
+@media only screen and (min-width: 1400px) {
+}
+
+@media only screen and (min-width: 1500px) {
+}
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/static/img/dkg.png b/website/i18n/fr/docusaurus-plugin-content-docs/static/img/dkg.png
new file mode 100644
index 00000000..f7aa2dbb
Binary files /dev/null and b/website/i18n/fr/docusaurus-plugin-content-docs/static/img/dkg.png differ
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/static/img/eth-moby-logo.png b/website/i18n/fr/docusaurus-plugin-content-docs/static/img/eth-moby-logo.png
new file mode 100644
index 00000000..41ed6c73
Binary files /dev/null and b/website/i18n/fr/docusaurus-plugin-content-docs/static/img/eth-moby-logo.png differ
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/static/img/ethereum-full-node.png b/website/i18n/fr/docusaurus-plugin-content-docs/static/img/ethereum-full-node.png
new file mode 100644
index 00000000..8b30c189
Binary files /dev/null and b/website/i18n/fr/docusaurus-plugin-content-docs/static/img/ethereum-full-node.png differ
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/static/img/ssv-node.png b/website/i18n/fr/docusaurus-plugin-content-docs/static/img/ssv-node.png
new file mode 100644
index 00000000..cd29380d
Binary files /dev/null and b/website/i18n/fr/docusaurus-plugin-content-docs/static/img/ssv-node.png differ
diff --git a/website/i18n/fr/docusaurus-plugin-content-docs/static/pdf/Sigma_Prime_Security_Audit_Findings_2023-05-04_v2.0.pdf b/website/i18n/fr/docusaurus-plugin-content-docs/static/pdf/Sigma_Prime_Security_Audit_Findings_2023-05-04_v2.0.pdf
new file mode 100644
index 00000000..cb4d7a08
Binary files /dev/null and b/website/i18n/fr/docusaurus-plugin-content-docs/static/pdf/Sigma_Prime_Security_Audit_Findings_2023-05-04_v2.0.pdf differ
diff --git a/website/i18n/fr/docusaurus-theme-classic/footer.json b/website/i18n/fr/docusaurus-theme-classic/footer.json
new file mode 100644
index 00000000..f6165f04
--- /dev/null
+++ b/website/i18n/fr/docusaurus-theme-classic/footer.json
@@ -0,0 +1,10 @@
+{
+  "copyright": {
+    "message": "Copyright © 2024 Eth Docker contributors",
+    "description": "The footer copyright"
+  },
+  "logo.alt": {
+    "message": "Eth Docker logo",
+    "description": "The alt text of footer logo"
+  }
+}
diff --git a/website/i18n/fr/docusaurus-theme-classic/navbar.json b/website/i18n/fr/docusaurus-theme-classic/navbar.json
new file mode 100644
index 00000000..6ca25639
--- /dev/null
+++ b/website/i18n/fr/docusaurus-theme-classic/navbar.json
@@ -0,0 +1,14 @@
+{
+  "title": {
+    "message": "Eth Docker Docs",
+    "description": "The title in the navbar"
+  },
+  "logo.alt": {
+    "message": "Eth Docker logo",
+    "description": "The alt text of navbar logo"
+  },
+  "item.label.Get Started": {
+    "message": "Get Started",
+    "description": "Navbar item with label Get Started"
+  }
+}