metal-stack · vknabel · Feb 20, 2026 · Gerrit91 · Feb 23, 2026
@@ -1,5 +1,6 @@
 ---
-slug: /community
+id: index
+slug: /
 title: Community
 sidebar_position: 1
 ---

@@ -6,7 +6,7 @@ sidebar_position: 18
 
 # Autonomous Control Plane
 
-As described in the [deployment chapter](../../../docs/04-For%20Operators/03-deployment-guide.md), we strongly recommend Kubernetes as the target platform for running the metal-stack control plane.
+As described in the [deployment chapter](/docs/deployment-guide), we strongly recommend Kubernetes as the target platform for running the metal-stack control plane.
 
 Kubernetes clusters for this purpose are readily available from hyperscalers, metalstack.cloud, or other cloud providers. Simply using a managed Kubernetes cluster greatly simplifies a metal-stack installation. However, sometimes it might be desirable to host the metal-stack control plane autonomously, without the help of another cloud provider. Reasons for this might include corporate policies that prohibit the use of external data center products, or network constraints.
 

@@ -14,7 +14,7 @@ As modern infrastructure and cloud native applications are designed with Kuberne
 
 Regardless which flavor of metal-stack you use, it is always possible to manually provision machines, networks and ip addresses. This is the most basic way of using metal-stack and is very similar to how traditional bare metal infrastructures are managed.
 
-Using plain metal-stack without additional layer was not a focus in the past. Therefore firewall and role management might be premature. These will be addressed by [MEP-4](../../contributing/04-Proposals/MEP4/README.md) and [MEP-16](../../contributing/04-Proposals/MEP16/README.md) in the future.
+Using plain metal-stack without additional layer was not a focus in the past. Therefore firewall and role management might be premature. These will be addressed by [MEP-4](/community/MEP-14-independence-from-external-sources) and [MEP-16](/community/MEP-16-metal-api-as-an-alternative-configuration-source-for-the-firewall-controller) in the future.
 
 ## Gardener
 

@@ -31,7 +31,7 @@ You can use the [mini-lab](https://github.com/metal-stack/mini-lab) as a templat
 The metal control plane is typically deployed in a Kubernetes cluster. Therefore, this document will assume that you have a Kubernetes cluster ready for getting deployed. Even though it is theoretically possible to deploy metal-stack without Kubernetes, we strongly advise you to use the described method because we believe that Kubernetes gives you a lot of benefits regarding the stability and maintainability of the application deployment.
 
 :::tip
-For metal-stack it does not matter where your control plane Kubernetes cluster is located. You can of course use a cluster managed by a hyperscaler. This has the advantage of not having to setup Kubernetes by yourself and could even become beneficial in terms of fail-safe operation. However, we also describe a solution of how to setup metal-stack with a self-hosted, [Autonomous Control Plane](../../contributing/04-Proposals/MEP18/README.md) cluster. The only requirement from metal-stack is that your partitions can establish network connections to the metal control plane. If you are interested, you can find a reasoning behind this deployment decision [here](../05-Concepts/01-architecture.mdx#target-deployment-platforms).
+For metal-stack it does not matter where your control plane Kubernetes cluster is located. You can of course use a cluster managed by a hyperscaler. This has the advantage of not having to setup Kubernetes by yourself and could even become beneficial in terms of fail-safe operation. However, we also describe a solution of how to setup metal-stack with a self-hosted, [Autonomous Control Plane](/community/MEP-18-autonomous-control-plane) cluster. The only requirement from metal-stack is that your partitions can establish network connections to the metal control plane. If you are interested, you can find a reasoning behind this deployment decision [here](../05-Concepts/01-architecture.mdx#target-deployment-platforms).
 :::
 
 Let's start off with a fresh folder for your deployment:
@@ -75,7 +75,7 @@ At the end of this section we are gonna end up with the following files and fold
 
 ### Releases and Ansible Role Dependencies
 
-As metal-stack consists of many microservices all having individual versions, we have come up with a [releases](https://github.com/metal-stack/releases) repository. It contains a YAML file (we often call it release vector) describing the fitting versions of all components for every release of metal-stack. Ansible role dependencies are also part of a metal-stack release. Both the metal-stack release vector and the metal-stack ansible-roles are shipped as OCI artifacts following a specific format that's described [here](../../contributing/06-oci-artifacts.md). These artifacts are signed with the CI token of the metal-stack Github organization and can be verified using [cosign](https://github.com/sigstore/cosign).
+As metal-stack consists of many microservices all having individual versions, we have come up with a [releases](https://github.com/metal-stack/releases) repository. It contains a YAML file (we often call it release vector) describing the fitting versions of all components for every release of metal-stack. Ansible role dependencies are also part of a metal-stack release. Both the metal-stack release vector and the metal-stack ansible-roles are shipped as OCI artifacts following a specific format that's described [here](/community/oci-artifacts). These artifacts are signed with the CI token of the metal-stack Github organization and can be verified using [cosign](https://github.com/sigstore/cosign).
 
 In order to download the release vector and the referenced ansible-roles prior to a deployment, we provide a small helper module called `metal_stack_release_vector` as part of the [metal-deployment-base](https://github.com/metal-stack/metal-deployment-base) deployment image. Its main tasks are:
 

@@ -152,4 +152,4 @@ Thus, for creating a partition as well as a machine or a firewall, the flags `dn
 
 In order to be fully offline resilient, make sure to check out `metal-image-cache-sync`. This component provides copies of `metal-images`, `metal-kernel` and `metal-hammer`.
 
-This feature is related to [MEP14](../../contributing/04-Proposals/MEP14/README.md).
+This feature is related to [MEP14](/community/MEP-14-independence-from-external-sources).
@@ -7,7 +7,7 @@ sidebar_position: 2
 # User Management
 
 At the moment, metal-stack can more or less be seen as a low-level API that does not scope access based on projects and tenants.
-Fine-grained access control with full multi-tenancy support is actively worked on in [MEP4](../../contributing/04-Proposals/MEP4/README.md).
+Fine-grained access control with full multi-tenancy support is actively worked on in [MEP4](/community/MEP-14-independence-from-external-sources).
 
 Until then projects and tenants can be created, but have no effect on access control.
 

@@ -15,7 +15,7 @@ The minimal need to know principle is a security concept that restricts access t
 ### RBAC
 
 :::info
-As of now metal-stack does not implement fine-grained Role-Based Access Control (RBAC) within the `metal-api` but this is worked on in [MEP-4](../../../contributing/04-Proposals/MEP4/README.md).
+As of now metal-stack does not implement fine-grained Role-Based Access Control (RBAC) within the `metal-api` but this is worked on in [MEP-4](/community/MEP-14-independence-from-external-sources).
 :::
 
 As described in our [User Management](../../05-Concepts/02-user-management.md) concept the [metal-api](https://github.com/metal-stack/metal-api) currently offers three different user roles for authorization:

@@ -116,7 +116,7 @@ Please note that every [networking setup](../../05-Concepts/03-Network/01-theory
 | VLAN       | Switches, Firewalls         | Layer 2 traffic segmentation.                                                                  |
 | VXLAN      | Switches, Firewalls         | Encapsulate Layer 2 frames in Layer 3 packets for network virtualization.                      |
 | EVPN       | Switches, Firewalls         | Overlay network technology for scalable and flexible network architectures.                    |
-| VPN        | Firewalls                   | Management access [without open SSH ports](../../../contributing/04-Proposals/MEP9/README.md). |
+| VPN        | Firewalls                   | Management access [without open SSH ports](..//community/MEP-9-no-open-ports-to-the-data-center).    |
-| VPN        | Firewalls                   | Management access [without open SSH ports](..//community/MEP-9-no-open-ports-to-the-data-center).    |
+| VPN        | Firewalls                   | Management access [without open SSH ports](/community/MEP-9-no-open-ports-to-the-data-center).    |
-| VPN        | Firewalls                   | Management access [without open SSH ports](..//community/MEP-9-no-open-ports-to-the-data-center).    |
+| VPN        | Firewalls                   | Management access [without open SSH ports](/community/MEP-9-no-open-ports-to-the-data-center).    |
 | BGP        | Multiple                    | Routing protocol for dynamic routing and network management.                                   |
 | SSH        | Management Server, Switches | Secure shell access for management and configuration.                                          |
 | LLDP       | Switches, Machines          | Link Layer Discovery Protocol for network device discovery.                                    |

@@ -31,4 +31,4 @@ To ensure that internal components interact securely with the metal-api, metal-s
 
 Users can interact with the metal-api using [metalctl](https://github.com/metal-stack/metalctl), the command-line interface provided by metal-stack. Depending on the required operations, users should authenticate with the appropriate role to match their level of access.
 
-As part of [MEP-4](../../contributing/04-Proposals/MEP4/README.md), significant work is underway to introduce more fine-grained access control mechanisms within metal-stack, enhancing the precision and flexibility of permission management.
+As part of [MEP-4](/community/MEP-14-independence-from-external-sources), significant work is underway to introduce more fine-grained access control mechanisms within metal-stack, enhancing the precision and flexibility of permission management.
@@ -6,7 +6,7 @@ title: Remote Access
 
 ## Machines and Firewalls
 
-Remote access to machines and firewalls is essential for performing administrative tasks such as incident management, troubleshooting and sometimes for development. Standard SSH access is often insufficient for these purposes. In many cases, direct serial console access is required to fully manage the system. metal-stack follows a security-first approach by not offering direct SSH access to machines. This practice reduces the attack surface and prevents unauthorized access that could lead to system damage. Detailed information can be found in [MEP-9](../../contributing/04-Proposals/MEP9/README.md). Administrators can access machines in two primary ways.
+Remote access to machines and firewalls is essential for performing administrative tasks such as incident management, troubleshooting and sometimes for development. Standard SSH access is often insufficient for these purposes. In many cases, direct serial console access is required to fully manage the system. metal-stack follows a security-first approach by not offering direct SSH access to machines. This practice reduces the attack surface and prevents unauthorized access that could lead to system damage. Detailed information can be found in [MEP-9](/community/MEP-9-no-open-ports-to-the-data-center). Administrators can access machines in two primary ways.
 
 **Out-of-band management via SOL**
 
@@ -26,4 +26,4 @@ This approach uses the [`metal-console`](../08-References/Control%20Plane/metal-
 
 Both methods ensure secure and controlled access to machines without exposing them unnecessarily to the network, maintaining the integrity and safety of the infrastructure.
 
-Connecting directly to a machine without a clear plan of action can have unintended consequences and negatively impact stability. For this reason, administrative privileges are required. This restriction ensures that only authorized personnel with the necessary expertise can perform actions that affect the underlying infrastructure. These principles will evolve with the introduction of [MEP-4](../../contributing/04-Proposals/MEP4/README.md).
+Connecting directly to a machine without a clear plan of action can have unintended consequences and negatively impact stability. For this reason, administrative privileges are required. This restriction ensures that only authorized personnel with the necessary expertise can perform actions that affect the underlying infrastructure. These principles will evolve with the introduction of [MEP-4](/community/MEP-14-independence-from-external-sources).
@@ -17,7 +17,7 @@ See original release note at [https://github.com/metal-stack/releases/releases/t
    ``` 
 * [Gardener v1.110](https://github.com/gardener/gardener/releases/tag/v1.110.0)
 ## Noteworthy
-* As part of the [MEP-4](https://docs.metal-stack.io/stable/development/proposals/MEP4/README/) implementation, it is now possible to deploy a preview version of the [metal-apiserver](https://github.com/metal-stack/metal-apiserver). Note that this is only a development preview and will undergo a lot of breaking changes in the next time, so do not deploy this for any production use cases yet. (metal-stack/metal-roles#391)
+* As part of the [MEP-4](/community/MEP-14-independence-from-external-sources) implementation, it is now possible to deploy a preview version of the [metal-apiserver](https://github.com/metal-stack/metal-apiserver). Note that this is only a development preview and will undergo a lot of breaking changes in the next time, so do not deploy this for any production use cases yet. (metal-stack/metal-roles#391)
 ## Breaking Changes
 * The support for meilisearch as an audit backend was dropped. Please migrate to the TimescaleDB backend if you depend on this implementation of meilisearch support. (metal-stack/metal-lib#174)
 ## Component Releases
@@ -73,4 +73,4 @@ The fact that these pull requests were merged does not necessarily imply that th
 * Add CODEOWNERS and code contribution guidelines. (metal-stack/sonic-configdb-utils#3) @Gerrit91
 * Try pushing to ghcr.io (metal-stack/metal-images#274) @majst01
 * fix(ci): forgot registry login (metal-stack/metal-images#292) @vknabel
-* Next release (metal-stack/releases#222) @metal-robot[bot]
+* Next release (metal-stack/releases#222) @metal-robot[bot]
Original file line number	Diff line number	Diff line change
Expand Up		@@ -152,4 +152,4 @@ Thus, for creating a partition as well as a machine or a firewall, the flags `dn

		In order to be fully offline resilient, make sure to check out `metal-image-cache-sync`. This component provides copies of `metal-images`, `metal-kernel` and `metal-hammer`.

		This feature is related to [MEP14](../../contributing/04-Proposals/MEP14/README.md).
		This feature is related to [MEP14](/community/MEP-14-independence-from-external-sources).
Original file line number	Diff line number	Diff line change
Expand Up		@@ -31,4 +31,4 @@ To ensure that internal components interact securely with the metal-api, metal-s

		Users can interact with the metal-api using [metalctl](https://github.com/metal-stack/metalctl), the command-line interface provided by metal-stack. Depending on the required operations, users should authenticate with the appropriate role to match their level of access.

		As part of [MEP-4](../../contributing/04-Proposals/MEP4/README.md), significant work is underway to introduce more fine-grained access control mechanisms within metal-stack, enhancing the precision and flexibility of permission management.
		As part of [MEP-4](/community/MEP-14-independence-from-external-sources), significant work is underway to introduce more fine-grained access control mechanisms within metal-stack, enhancing the precision and flexibility of permission management.