# Testing Methodologies Standards for Hetzner

This document outlines the testing methodologies standards for Hetzner infrastructure and application deployment. It is designed to guide developers in ensuring the reliability, performance, and security of solutions built on the Hetzner Cloud platform. These standards will serve as context for AI coding assistants, promoting consistency and quality across all projects.

## 1. Introduction to Testing in Hetzner

High-quality testing is crucial for building robust and reliable applications in the Hetzner ecosystem. Due to the distributed nature of cloud deployments, a comprehensive testing strategy is vital. This standard establishes guidelines for effectively testing applications and infrastructure deployed on Hetzner Cloud. It covers unit tests, integration tests, end-to-end tests, and considerations specific to Hetzner’s features and services.

## 2. Unit Testing

### 2.1 Standard: Isolate Units for Testing

**Do This:** Write unit tests that isolate individual components (functions, classes, or modules) to verify their behavior in isolation. Use mocking or stubbing to replace dependencies.

**Don't Do This:** Avoid writing unit tests that rely on external services or databases, as this makes them slow, unreliable, and difficult to maintain. Never skip unit tests for critical modules due to perceived complexity.

**Why This Matters:** Unit tests are the fastest and most reliable form of testing. They help detect errors early in the development cycle, making them easier and cheaper to fix.

**Code Example (Python):**

"""python

# app/calculator.py

class Calculator:

def add(self, a, b):

return a + b

# tests/test_calculator.py

import unittest

from unittest.mock import MagicMock

from app.calculator import Calculator

class TestCalculator(unittest.TestCase):

def test_add(self):

calc = Calculator()

result = calc.add(2, 3)

self.assertEqual(result, 5)

"""

**Anti-Pattern:** Writing unit tests that interact with database connections or Hetzner Cloud APIs directly leads to flaky tests.

**Hetzner Specific Detail:** When using Hetzner's Load Balancers, ensure unit tests for backend services stub out the load balancer interaction.

### 2.2 Standard: Test All Code Paths

**Do This:** Aim for high test coverage by writing tests that exercise all possible execution paths within a unit. Cover all conditional branches, loops, and error handling logic.

**Don't Do This:** Do not ignore edge cases or error scenarios. A test suite with low coverage can give a false sense of security.

**Why This Matters:** Comprehensive test coverage helps ensure that all parts of the code are working correctly, even under unusual circumstances.

**Code Example (Go):**

"""go

// calculator.go

package calculator

import "errors"

func Divide(a, b float64) (float64, error) {

if b == 0 {

return 0, errors.New("cannot divide by zero")

}

return a / b, nil

}

// calculator_test.go

package calculator

import "testing"

func TestDivide(t *testing.T) {

t.Run("Valid Division", func(t *testing.T) {

result, err := Divide(10, 2)

if err != nil {

t.Errorf("Expected no error, got %v", err)

}

if result != 5 {

t.Errorf("Expected 5, got %f", result)

}

})

t.Run("Divide by Zero", func(t *testing.T) {

_, err := Divide(10, 0)

if err == nil {

t.Errorf("Expected an error, got nil")

}

})

}

"""

**Anti-Pattern:** Only testing happy path scenarios and neglecting error conditions and edge cases.

**Hetzner Specific Detail:** If using Hetzner's Object Storage, ensure that unit tests for code interacting with the storage service mock the API responses properly.

### 2.3 Standard: Assertions and Expected Outcomes

**Do This:** Use clear and specific assertions to verify that the code behaves as expected. Ensure that assertions are easy to understand and provide meaningful error messages when they fail. Use descriptive test names.

**Don't Do This:** Avoid using generic assertions that only check for the absence of errors. Don't use vague test names that don't explain what's supposed to happen.

**Why This Matters:** Clear assertions make it easier to diagnose and fix problems when tests fail.

**Code Example (JavaScript with Jest):**

"""javascript

// calculator.js

function multiply(a, b) {

return a * b;

}

// calculator.test.js

test('multiplies two numbers correctly', () => {

expect(multiply(2, 3)).toBe(6);

});

"""

**Anti-Pattern:** Writing tests with assertions that do not clearly define expected outcomes.

## 3. Integration Testing

### 3.1 Standard: Verify Interactions Between Components

**Do This:** Write integration tests to verify that different components of the application work together correctly. Focus on testing the interactions between modules, services, and external systems. Use test containers to simulate the environment.

**Don't Do This:** Avoid writing integration tests that are too broad or too narrow. Don't create integration tests with a massive scope, making debugging difficult.

**Why This Matters:** Integration tests ensure that the different parts of the application are compatible and work seamlessly together.

**Code Example (Docker Compose and Python):**

*docker-compose.yml*

"""yaml

version: "3.8"

services:

app:

build: .

ports:

- "5000:5000"

depends_on:

- db

environment:

- DATABASE_URL=postgresql://user:password@db:5432/app_db

db:

image: postgres:13

environment:

- POSTGRES_USER=user

- POSTGRES_PASSWORD=password

- POSTGRES_DB=app_db

"""

*test\_integration.py*

"""python

import unittest

import requests

import os

class TestIntegration(unittest.TestCase):

def setUp(self):

self.app_url = "http://localhost:5000" # Assuming app runs on port 5000

def test_app_db_connection(self):

try:

response = requests.get(f"{self.app_url}/health") # Using a /health endpoint example. Add relevant test endpoint.

response.raise_for_status() # Raises HTTPError for bad responses (4xx or 5xx)

self.assertEqual(response.status_code, 200)

except requests.exceptions.RequestException as e:

self.fail(f"Request failed: {e}")

"""

**Anti-Pattern:** Skipping integration tests due to complexity in setting up the environment often leads to issues in production.

**Hetzner Specific Detail:** For applications leveraging Hetzner's managed databases, integration tests should verify connectivity and data integrity within the Hetzner environment. Use "testcontainers" or similiar libraries for containerized integration tests.

### 3.2 Standard: Test Data Management

**Do This:** Manage test data carefully to ensure that tests are repeatable and reliable. Use dedicated test databases or schemas to avoid polluting production data. Clean up test data after each test run.

**Don't Do This:** Avoid using hardcoded test data or relying on shared test data that can be modified by other tests. Do not skip data cleanup, causing test pollution.

**Why This Matters:** Proper test data management prevents tests from interfering with each other and ensures that tests produce consistent results.

**Code Example (SQLAlchemy and Python):**

"""python

# test_data_manager.py

from sqlalchemy import create_engine

from sqlalchemy.orm import sessionmaker

from your_app import Base # Imports Base from your application

DATABASE_URL = "postgresql://test_user:test_password@localhost:5432/test_db"

engine = create_engine(DATABASE_URL)

TestingSessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)

def create_test_database():

Base.metadata.create_all(bind=engine)

def drop_test_database():

Base.metadata.drop_all(bind=engine)

def get_test_db():

db = TestingSessionLocal()

try:

yield db

finally:

db.close()

"""

"""python

# your_test.py

import unittest

from test_data_manager import create_test_database, drop_test_database, get_test_db

from your_app import YourModel # Import app's model

class YourTest(unittest.TestCase):

@classmethod

def setUpClass(cls):

create_test_database() # Setup the test database once for the class

@classmethod

def tearDownClass(cls):

drop_test_database() # Drop the test database after tests are done

def setUp(self):

self.db = next(get_test_db()) # Get a fresh DB session for each test

# Add any default data needed for tests each time

self.db.add(YourModel(name="Test Data"))

self.db.commit()

def tearDown(self):

self.db.rollback() # Rollback any transaction made in test

self.db.query(YourModel).delete() # Clear out the data

self.db.commit()

self.db.close() # Close the DB session

def test_your_endpoint(self):

# Test Logic here

pass

"""

**Hetzner Specific Detail:** When running integration tests against resources on Hetzner Cloud, use unique naming conventions or dedicated testing resources to avoid conflicts with production environments. Always use environment variables instead of hardcoding credentials. For example:

"""bash

export HCLOUD_TOKEN="your_hetzner_cloud_token"

"""

### 3.3 Standard: Test Dependencies Using Service Containers

**Do This:** Utilize containerization, such as Docker, to manage and isolate test dependencies. This creates a reproducible test environment. Ensure proper configuration is set up for each container.

**Don't Do This:** Relying on system-wide dependencies for integration tests that are not containerized, as this can lead to inconsistent and unreliable results.

**Why This Matters:** Service containers ensure a consistent and isolated testing environment, minimizing the risk of environment-specific issues.

**Code Example (Using Docker Compose for PostgreSQL):**

"""yaml

version: "3.8"

services:

db:

image: postgres:13

ports:

- "5432:5432"

environment:

POSTGRES_USER: test_user

POSTGRES_PASSWORD: test_password

POSTGRES_DB: test_db

"""

Then, within your integration tests:

"""python

import psycopg2

def test_database_connection():

try:

conn = psycopg2.connect(

host="localhost", # Or the Docker Compose service name "db" if running within the same network

port=5432,

user="test_user",

password="test_password",

database="test_db"

)

cursor = conn.cursor()

cursor.execute("SELECT 1")

result = cursor.fetchone()

assert result[0] == 1

except psycopg2.Error as e:

assert False, f"Database connection failed: {e}"

finally:

if conn:

cursor.close()

conn.close()

"""

**Anti-Pattern:** Running integration tests that depend on manually installed services often results in brittle and unreliable execution.

## 4. End-to-End Testing

### 4.1 Standard: Simulate Real User Scenarios

**Do This:** Write end-to-end (E2E) tests to simulate real user interactions with the application. Design E2E tests that cover the most critical user flows, such as registration, login, and common tasks.

**Don't Do This:** Avoid writing E2E tests that are too granular or too complex. Overly complex E2E tests are hard to maintain and debug. Don't cover scenarios that are already covered by unit or integration testing.

**Why This Matters:** E2E tests ensure that the application works correctly from the user's perspective, including all the different layers and dependencies.

**Code Example (Selenium with Python):**

"""python

from selenium import webdriver

from selenium.webdriver.common.by import By

import unittest

class TestE2E(unittest.TestCase):

def setUp(self):

self.driver = webdriver.Chrome() # Ensure ChromeDriver is installed and in PATH

self.driver.get("http://localhost:8000") # Replace with your app's URL

def tearDown(self):

self.driver.quit()

def test_login(self):

username_input = self.driver.find_element(By.ID, "username")

password_input = self.driver.find_element(By.ID, "password")

login_button = self.driver.find_element(By.ID, "login-button")

username_input.send_keys("testuser")

password_input.send_keys("password123")

login_button.click()

# Assert that we logged in successfully

self.assertEqual(self.driver.current_url, "http://localhost:8000/dashboard")

"""

**Anti-Pattern:** Skimping on E2E tests due to their overhead and complexity, as these tests are crucial for verifying the entire system's functionality.

**Hetzner Specific Detail:** If an application interacts with Hetzner Cloud services from the frontend, simulate these interactions in E2E tests, such as creating a server or modifying firewall rules. Ensure you clean up these resources after the test runs.

### 4.2 Standard: Test Environment Parity

**Do This:** Use a test environment that closely mirrors the production environment, including the same operating system, web server, database, and dependencies. Configure the test environment to use realistic data volumes and network configurations.

**Don't Do This:** Do not test in an environment that is significantly different from production, as this can lead to false positives and false negatives. Also, avoid using simplified or scaled-down environments for E2E testing.

**Why This Matters:** Environment parity ensures that the tests accurately reflect the behavior of the application in production.

**Code Example (Terraform for environment creation):**

"""terraform

# main.tf

resource "hcloud_server" "test_server" {

name = "e2e-test-server"

server_type = "cx11"

image = "ubuntu-22.04"

location = "fsn1" # Change to your desired location

}

# outputs.tf

output "server_ip" {

value = hcloud_server.test_server.ipv4_address

}

"""

**Anti-Pattern:** Testing on local development machines and not validating the solution on a production-like environment hosted on Hetzner.

### 4.3 Standard: Monitoring and Logging during tests

**Do This:** Implement comprehensive monitoring and logging during E2E test execution. Analyze logs and metrics to identify performance bottlenecks and errors.

**Don't Do This:** Do not run E2E tests without proper monitoring, making it difficult to pinpoint the root cause of a failure. Don't ignore unusual performance metrics during testing.

**Why This Matters:** Monitoring and logging enable you to identify and diagnose problems that may not be immediately apparent from the test results.

**Code Example (Integrating Prometheus and Grafana):**

1. **Install Prometheus and Grafana:** Deploy Prometheus and Grafana on Hetzner Cloud (e.g., using Docker).

2. **Configure Prometheus to scrape the application:** Expose application metrics (e.g., using Micrometer in Java or Prometheus client library for Python).

3. **Create Grafana dashboards:** Visualize key performance indicators (KPIs) during E2E test runs.

**Hetzner Specific Detail:** Leverage Hetzner's metrics exporter to gather and analyze server-level metrics, such as CPU usage, memory consumption, and network traffic, during E2E testing.

## 5. Security Testing

### 5.1 Standard: Security Scanning

**Do This:** Use automated security scanning tools to identify vulnerabilities in the application and infrastructure. Integrate security scanning into the CI/CD pipeline. Test for common security flaws. Integrate tools like Clair, Trivy, or custom scripts.

**Don't Do This:** Do not rely solely on manual security reviews. Do not skip security scanning due to time constraints.

**Why This Matters:** Automated security scanning helps detect and remediate vulnerabilities before they can be exploited.

**Code Example (Using Trivy in a CI/CD pipeline):**

"""yaml

# .gitlab-ci.yml

stages:

- build

- test

build:

stage: build

image: docker:latest

services:

- docker:dind

script:

- docker build -t my-app .

- docker save -o my-app.tar my-app

artifacts:

paths:

- my-app.tar

security_scan:

stage: test

image: aquasec/trivy:latest

script:

- trivy image --severity HIGH,CRITICAL --exit-code 0 my-app

"""

### 5.2 Standard: Authentication and Authorization

**Do This:** Thoroughly test authentication and authorization mechanisms to ensure that users can only access the resources they are authorized to access. Test for common vulnerabilities such as broken authentication, authorization flaws, and session management issues.

**Don't Do This:** Do not use default credentials. Do not rely on client-side validation for security.

**Why This Matters:** Authentication and authorization are critical for protecting sensitive data and preventing unauthorized access.

**Code Example (Testing authentication):**

"""python

import requests

import unittest

class TestAuth(unittest.TestCase):

def test_login_success(self):

data = {'username': 'valid_user', 'password': 'valid_password'}

r = requests.post('http://localhost:5000/login', data=data) # Replace URL

self.assertEqual(r.status_code, 200) #Check HTTP Status

def test_login_fail(self):

data = {'username': 'valid_user', 'password': 'wrong_password'}

r = requests.post('http://localhost:5000/login', data=data) # Replace URL

self.assertEqual(r.status_code, 401) #Check HTTP Status

"""

**Hetzner Specific Detail:** When using Hetzner's firewall, regularly test firewall rules to ensure they are correctly configured and prevent unauthorized access to servers.

### 5.3 Standard: Data Validation

**Do This:** Validate all input data to prevent injection attacks (SQL injection, cross-site scripting). Use parameterized queries or ORMs to prevent SQL injection, and sanitize user input to prevent XSS attacks.

**Don't Do This:** Do not trust user input. Do not disable input validation.

**Why This Matters:** Data validation is essential for preventing a wide range of security vulnerabilities.

## 6. Performance Testing

### 6.1 Standard: Load Testing

**Do This:** Perform load testing to evaluate the application's behavior under heavy load. Identify performance bottlenecks and ensure that the application can handle the expected traffic volume. Use tools like Locust, JMeter, or k6.io.

**Don't Do This:** Do not deploy applications without load testing. Do not underestimate expected traffic volume.

**Why This Matters:** Load testing helps ensure that the application can handle peak traffic and prevent performance degradation.

**Code Example (Locustfile):**

"""python

from locust import HttpUser, task, between

class QuickstartUser(HttpUser):

wait_time = between(1, 2)

@task

def hello_world(self):

self.client.get("/hello") # Define test endpoint

"""

### 6.2 Standard: Monitoring Application Performance

**Do This:** Instrument applications with tools that can expose metrics for monitoring performance. Tools like Prometheus, Grafana, and the ELK stack help track application performance in real-time.

**Don't Do This:** Ignore performance monitoring, as this is crucial for identifying and addressing bottlenecks.

**Why This Matters:** Monitoring helps identify performance issues and allows for proactive optimization.

**Hetzner Specific Detail:** Leverage Hetzner Cloud's monitoring features to track server performance metrics, such as CPU usage, memory consumption, and network traffic.

### 6.3 Standard: Scalability Testing

**Do This:** Verify application scalability by testing its ability to handle increased load by adding resources. This includes horizontal (adding more servers) and vertical (increasing server resources) scaling.

**Don't Do This:** Neglect to test scalability, as the long-term implications can be detrimental.

## 7. Automation and CI/CD

### 7.1 Standard: Integrate Testing into CI/CD

**Do This:** Integrate all types of tests into the CI/CD pipeline to ensure that code changes are automatically tested before being deployed to production. Implement automated deployment pipelines to Hetzner Cloud.

**Don't Do This:** Deploy code without automated testing. Manually run tests, as this introduces delays and inconsistencies.

**Why This Matters:** Automated testing in the CI/CD pipeline ensures that code changes are thoroughly tested, reducing the risk of introducing bugs into production.

**Code Example (GitLab CI with integration tests):**

"""yaml

stages:

- test

integration_tests:

image: python:3.9

stage: test

services:

- postgres:13

variables:

DATABASE_URL: postgresql://user:password@postgres:5432/testdb

before_script:

- pip install -r requirements.txt

script:

- python -m unittest discover -s tests -p "test_integration*.py"

"""

### 7.2 Standard: Test Environment Provisioning

**Do This:** Automate the provisioning and configuration of test environments using infrastructure-as-code tools like Terraform. Ensure all necessary services and dependencies are automatically set up for each test run.

**Don't Do This:** Manually set up test environments, resulting in inconsistencies and increased setup time.

**Why This Matters:** Automated test environment provisioning ensures that test environments are consistent and repeatable, reducing the risk of environment-specific issues.

### 7.3 Standard: Infrastructure Testing

**Do This:** Implement infrastructure tests to validate that infrastructure components are correctly provisioned and configured. Utilize tools like Terraform for infrastructure testing.

## 8. Documentation and Reporting

### 8.1 Standard: Document Test Plans and Results

**Do This:** Document the test plan, including the scope, objectives, and test cases. Provide clear, detailed reports of test results.

**Don't Do This:** Skip test documentation, as this hinders the ability to track progress, analyze results, and make informed decisions about code quality. Don't generate ambiguous or incomplete reports.

**Why This Matters:** Detailed documentation facilitates collaboration, knowledge sharing, and continuous improvement of the testing process.

### 8.2 Standard: Centralized Test Reporting

**Do This:** Centralize test reporting using tools like TestRail, Xray, or similar solutions to track test execution results and identify trends, metrics, and areas for improvement.

### 8.3 Standard: Communicating Results

**Do This:** Create clear, concise reports that are easily understood by all stakeholders. Communicate with the development team to rapidly address test failures.

## 9. Hetzner Specific Considerations

### 9.1 Standard: Testing Network Configurations

**Do This:** Write tests to validate network configurations on Hetzner Cloud, including firewall rules, load balancer settings, and VPN connections. Use tools like "nmap" or "tcpdump" in test scripts to verify that the network is configured as expected.

**Why This Matters:** Correct network configuration is essential for security and performance.

### 9.2 Standard: Testing Instance Lifecycle Events

**Do This:** Implement tests to handle server lifecycle events on Hetzner Cloud, such as server creation, deletion, and resizing.

**Why This Matters:** Proper handling of lifecycle events is critical for maintaining application availability and reliability.

### 9.3 Standard: Resource Cleanup

**Do This:** Ensure that all test resources created on Hetzner Cloud are automatically cleaned up after each test run to avoid unnecessary costs.

## 10. Future Trends

### 10.1 Continuous Testing

Embrace the concept of continuous testing by integrating testing into every stage of the software delivery lifecycle. Use tools and practices like shift-left testing to detect issues earlier and enable faster feedback loops.

### 10.2 AI-Driven Testing

Explore the use of AI and machine learning to automate test case generation, execution, and analysis. Implement AI-powered tools to identify patterns and anomalies in test data, leading to more efficient and effective testing.

### 10.3 Chaos Engineering

Implement chaos engineering principles to proactively identify weaknesses and vulnerabilities in the application and infrastructure. Conduct controlled experiments to simulate failures and disruptions to assess resilience and improve system recovery.

By adhering to these testing standards, developers can ensure the delivery of high-quality, reliable, and secure applications on the Hetzner Cloud platform.

Cline

This guide explains how to effectively use .clinerules with Cline, the AI-powered coding assistant.

Overview

The .clinerules file is a powerful configuration file that helps Cline understand your project's requirements, coding standards, and constraints. When placed in your project's root directory, it automatically guides Cline's behavior and ensures consistency across your codebase.

Key Concepts

Purpose of .clinerules

Defines project-specific guidelines and requirements
Enforces consistent coding standards
Establishes documentation practices
Sets testing and quality requirements
Configures error handling preferences

File Location

Place the .clinerules file in your project's root directory. Cline automatically detects and follows these rules for all files within the project.

Rule Structure

1. Project Overview

# Project Overview
project:
  name: 'Your Project Name'
  description: 'Brief project description'
  stack:
    - technology: 'Framework/Language'
      version: 'X.Y.Z'
    - technology: 'Database'
      version: 'X.Y.Z'

2. Code Standards

# Code Standards
standards:
  style:
    - 'Use consistent indentation (2 spaces)'
    - 'Follow language-specific naming conventions'
  documentation:
    - 'Include JSDoc comments for all functions'
    - 'Maintain up-to-date README files'
  testing:
    - 'Write unit tests for all new features'
    - 'Maintain minimum 80% code coverage'

3. Security Rules

# Security Guidelines
security:
  authentication:
    - 'Implement proper token validation'
    - 'Use environment variables for secrets'
  dataProtection:
    - 'Sanitize all user inputs'
    - 'Implement proper error handling'

Best Practices

Writing Effective Rules

Be Specific
- Use clear, actionable language
- Provide examples where helpful
- Define measurable criteria
Maintain Organization
- Group related rules together
- Use consistent formatting
- Keep critical rules at the top
Regular Updates
- Review rules periodically
- Update based on team feedback
- Document changes in version control

Common Patterns

# Common Patterns Example
patterns:
  components:
    - pattern: 'Use functional components by default'
    - pattern: 'Implement error boundaries for component trees'
  stateManagement:
    - pattern: 'Use React Query for server state'
    - pattern: 'Implement proper loading states'

Integration with Development Workflow

Using with Version Control

Commit the Rules
- Include .clinerules in version control
- Document rule changes in commit messages
- Review rule changes as part of PR process
Team Collaboration
- Discuss rule changes with team
- Maintain changelog for rule updates
- Ensure all team members understand rules

Troubleshooting

Common Issues

Rules Not Being Applied
- Verify file location (must be in root directory)
- Check file formatting
- Ensure Cline has access to the file
Conflicting Rules
- Review rule hierarchy
- Resolve conflicts explicitly
- Document rule precedence
Performance Considerations
- Keep rules concise and focused
- Avoid overly complex rule structures
- Regular cleanup of obsolete rules

Examples

Basic Project Setup

# Basic .clinerules Example
project:
  name: 'Web Application'
  type: 'Next.js Frontend'
  standards:
    - 'Use TypeScript for all new code'
    - 'Follow React best practices'
    - 'Implement proper error handling'

testing:
  unit:
    - 'Jest for unit tests'
    - 'React Testing Library for components'
  e2e:
    - 'Cypress for end-to-end testing'

documentation:
  required:
    - 'README.md in each major directory'
    - 'JSDoc comments for public APIs'
    - 'Changelog updates for all changes'

Advanced Configuration

# Advanced .clinerules Example
project:
  name: 'Enterprise Application'
  compliance:
    - 'GDPR requirements'
    - 'WCAG 2.1 AA accessibility'

architecture:
  patterns:
    - 'Clean Architecture principles'
    - 'Domain-Driven Design concepts'

security:
  requirements:
    - 'OAuth 2.0 authentication'
    - 'Rate limiting on all APIs'
    - 'Input validation with Zod'

Testing Methodologies Standards for Hetzner

Cline

Overview

Key Concepts

Purpose of .clinerules

File Location

Rule Structure

1. Project Overview

2. Code Standards

3. Security Rules

Best Practices

Writing Effective Rules

Common Patterns

Integration with Development Workflow

Using with Version Control

Troubleshooting

Common Issues

Examples

Basic Project Setup

Advanced Configuration

Related Rules

API Integration Standards for Hetzner

Component Design Standards for Hetzner

Performance Optimization Standards for Hetzner

Deployment and DevOps Standards for Hetzner

Tooling and Ecosystem Standards for Hetzner