Claude Code is a powerful command-line tool that brings AI-powered code generation and analysis to your terminal. While it defaults to Anthropic’s API, you can extend its capabilities by configuring it to work with different AI providers. This guide shows you how to set up Claude Code with various providers to access free and paid model options.

Installing Claude Code

First, install Claude Code for your operating system.

Windows

Run with PowerShell:

irm https://claude.ai/install.ps1 | iex

Linux & macOS

curl -fsSL https://claude.ai/install.sh | bash

Setting up the Environment Path for claude.exe (Windows)

After installation, add the Claude Code binary folder to your system PATH environment variable.

C:\Users\USERNAME\.local\bin

Configuration with Environment Variables

Claude Code can be configured using environment variables to work with different providers. Here are the key environment variables:

• ANTHROPIC_BASE_URL - The API endpoint (default: https://api.anthropic.com)
• ANTHROPIC_MODEL - The selected model to use
• ANTHROPIC_AUTH_TOKEN - Your API key or authentication token
• ANTHROPIC_CUSTOM_HEADERS - Custom headers for specific providers (optional)

# Make sure you have installed Node.js
npx claude-code-profile-switcher

Select a provider and model, enter your API key, then click save. The tool will store these as environment variables based on your operating system. Make sure you open a new terminal after setting environment variables.

Default Model

Run Claude Code with the default configured model:

claude

Specific Model

Run Claude Code with a specific model using the --model flag:

claude --model z-ai/glm-5

Skip Permission Checks

If needed, you can skip permission confirmations with the --allow-dangerously-skip-permissions flag:

claude --model moonshotai/kimi-k2.5 --allow-dangerously-skip-permissions

Finding Free and Trial Providers

Many providers offer free and trial LLMs that work with Claude Code. Check out this comprehensive list:

Free and Trial Providers List

Bonus: Add Claude Code to Windows Context Menu

Make Claude Code even more convenient by adding it to your Windows right-click context menu.

Install Context Menu

powershell -ExecutionPolicy Bypass -Command "irm https://raw.githubusercontent.com/bariskisir/ClaudeCodeContextMenu/master/install.ps1 | iex"

Uninstall Context Menu

powershell -ExecutionPolicy Bypass -Command "irm https://raw.githubusercontent.com/bariskisir/ClaudeCodeContextMenu/master/uninstall.ps1 | iex"

References & Documentation

Claude Code Quick Start - https://code.claude.com/docs/en/quickstart

LLM Gateway - https://code.claude.com/docs/en/llm-gateway

Model Configuration - https://code.claude.com/docs/en/model-config

Environment Variables - https://code.claude.com/docs/en/env-vars

Claude Code Context Menu - https://github.com/bariskisir/ClaudeCodeContextMenu

OpenCode Context Menu - https://github.com/bariskisir/OpenCodeContextMenu

Codex Context Menu - https://github.com/bariskisir/CodexContextMenu

Gemini Context Menu - https://github.com/bariskisir/GeminiContextMenu

In Chess960, the starting position is randomly selected from 960 possibilities before the match, with two rules: Bishops must be on opposite colors, and the King must be between the Rooks.

Have you ever wondered if the “First Move Advantage” in chess is actually fair? Or does randomization in Chess960 (Fischer Random) introduce a hidden “Luck Factor” that we haven’t fully quantified?

In standard chess, we know White starts with a slight edge. But what happens when you shuffle the pieces into one of 960 random positions? Is every starting position created equal? I decided to find out using Stockfish 18 at a consistent Depth 25.

The “Luck” Gap

I analyzed all 960 starting positions. The results were fascinating—and a bit concerning for competitive integrity.

While standard chess (Position 518) gives White a familiar +0.32 advantage, some shuffle variations push this number to nearly +0.80. To put that in perspective, +0.80 is almost a full pawn advantage without a single move being played.

On the flip side, some setups are incredibly docile, evaluating at a dead 0.00.

The Unofficial “Luck Factor”: If the randomizer selects ID #80 (Highest Advantage), White is effectively gifted a winning advantage. If ID #644 is selected, the game starts dead even. In a short tournament format, this variance matters.

The Data

Here are the positions where the “Luck of the Draw” heavily favors White, and the positions where Black has the easiest time equalizing.

🏛️ White’s Top 10 (Highest Advantage)

Randomization gifts White a massive head start here. Eval is near +0.80.

🛡️ Black’s Top 10 (Least Disadvantage)

These positions are effectively drawn from move 1. Eval is -0.01 to +0.12.

Conclusion

Chess960 succeeds in killing memorization, but it introduces a new variable: Randomness. While aiming to test pure skill, it inadvertently tests a player’s ability to adapt to “lucky” or “unlucky” starting evaluations.

However, this analysis is strictly for engines. For humans, the reality is different. Being White in a completely unfamiliar position—without centuries of theory to guide you—can actually feel like a disadvantage. You are forced to formulate a plan from scratch while under pressure, often making the “First Move Advantage” purely theoretical.

Perhaps true fairness isn’t about equal engine evaluations, but about how well you can navigate the unique chaos you’re dealt.

This analysis was inspired by the FIDE Freestyle Chess World Championship (Feb 13-15, 2026).

References & Downloads

• Tournament: FIDE Freestyle Chess World Championship - Weissenhaus
• Project Code: GitHub Repository
• Full Analysis Data: Download results.csv

With the proliferation of Apple Silicon (M-series) in development and cost-effective ARM-based instances (like AWS Graviton) in production, the ability to build and distribute multi-platform container images is no longer a luxury—it’s a necessity for modern CI/CD pipelines.

The Problem with docker build

A standard docker build creates an image for the architecture of the host machine. If you build an image on an Intel-based CI server, it will fail to launch on an ARM-based production cluster.

Introducing Docker Buildx

Docker Buildx is a specialized CLI plugin that extends the docker command with full support for multi-platform builds using BuildKit.

Implementation: The Unified Build Command

Using the --platform flag, you can orchestrate Docker to build for multiple architectures simultaneously and push them as a single Manifest List to your registry.

# Create a new builder instance with multi-arch support
docker buildx create --use --name multi-arch-builder

# Build and Push for both Intel (amd64) and ARM (arm64)
docker buildx build --platform linux/amd64,linux/arm64 \
  -t username/enterprise-app:v1.2 --push .

Orchestrating the Dockerfile for Multi-Arch

To ensure your Dockerfile is architecture-agnostic, rely on the official .NET images which provide multi-arch manifests out of the box.

# Docker automatically pulls the correct architecture for the 'sdk' tag
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app/out

# Final lightweight runtime image
FROM mcr.microsoft.com/dotnet/runtime:8.0
WORKDIR /app
COPY --from=build /app/out .
ENTRYPOINT ["dotnet", "App.dll"]

Strategic Advantages

1. Cost Efficiency: ARM instances are typically 20-40% cheaper than equivalent x86 instances.
2. Performance: ARM architectures often provide superior performance for specific workloads, such as cryptographic operations or high-concurrency microservices.
3. Developer Experience: Ensures that developers on different hardware (Mac vs. Windows/Linux) are testing the exact same container manifest that will run in production.

The Advantage of Platform Agnostic Infrastructure

We are moving toward a world where the underlying CPU architecture should be an implementation detail, not a deployment blocker. By integrating Buildx and multi-arch manifests into your CI/CD pipeline, you empower your operations team to choose the most cost-effective or highest-performing hardware without requiring a single change to your application code. It’s about building once and knowing your software is ready for whatever infrastructure comes next.

JSON Web Tokens (JWT) are ubiquitous in modern API development. However, their perceived simplicity often masks critical security flaws that expose applications to token forgery, identity theft, and replay attacks.

1. Storing Refresh Tokens in Plaintext

Storing refresh tokens as raw strings in your database is a significant security oversight. If your database is compromised, an attacker can use these plaintext tokens to forge new access tokens at will. This creates a high-impact session hijacking scenario—reminiscent of vulnerabilities in legacy session management systems—where an attacker can maintain persistent access to a user’s account without ever knowing their credentials.

• Fix: Always treat refresh tokens like passwords. Store only their cryptographically hashed versions (e.g., using SHA-256) and validate the incoming token’s hash against the stored value during the refresh flow.

2. Weak Signing Secrets

Using a short or predictable string for your IssuerSigningKey is a catastrophic vulnerability. Attackers can use brute-force tools (like jwt-cracker) to discover the secret and sign their own administrative tokens.

• Fix: Use a cryptographically strong, 256-bit (32 character) minimum secret key, ideally stored in a managed key vault.

3. Storing Sensitive Data in Claims

Remember that JWT payloads are encoded, not encrypted. Anyone with access to the token string can decode it (via jwt.io) and read the claims.

• Fix: Never store passwords, SSNs, or sensitive PII in the token. Only include non-sensitive metadata like sub (user ID) and role.

4. Ignoring Token Revocation

Because JWTs are stateless, there is no built-in way to “log out” a user if their token is compromised.

• Fix: Implement a Token Blacklist (via Redis) or, preferably, utilize Refresh Tokens stored in a secure database. Set the Access Token expiration to a very short duration (e.g., 15 minutes).

5. Not Validating Critical Parameters

Many implementations fail to strictly validate the Issuer, Audience, and Lifetime.

• Fix: Ensure your TokenValidationParameters are configured correctly:

options.TokenValidationParameters = new TokenValidationParameters
{
    ValidateIssuer = true,
    ValidateAudience = true,
    ValidateLifetime = true,
    RequireExpirationTime = true,
    ClockSkew = TimeSpan.Zero // Remove the default 5-minute leeway
};

Security as a Continuous Discipline

The simplicity of JWTs is exactly what makes them dangerous. It’s easy to ship an implementation that “works,” but much harder to ship one that is resilient against a determined attacker. Avoiding these top five mistakes—especially around signing secrets, refresh token storage, and revocation—moves your API from a “good enough” security posture to one that is built on industry-standard defensive patterns. Remember, in security, the smallest oversight is often the largest open door.

“Just add a cache” is a common response to performance issues. However, an incorrectly implemented distributed cache (like Redis) can introduce subtle bugs, data inconsistency, and even degrade performance through network congestion or serial overhead.

Common Anti-Patterns

1. The Cache Stampede: When a highly requested key expires, multiple concurrent requests attempt to regenerate the data simultaneously, overwhelming your database.
2. Large Object Serialization: Storing massive object graphs (multi-megabyte JSON strings) in Redis causes high latency during network transmission and CPU spikes during deserialization.
3. Missing TTL Strategy: Inconsistent Time-To-Live (TTL) values leading to “stale data” bugs that are notoriously difficult to reproduce in development environments.

Advanced Strategies: The Two-Level Cache

To mitigate the network overhead of Redis for extremely hot keys, implement a Two-Level Cache (L1: In-Memory, L2: Redis).

public async Task<T> GetWithTwoLevelCache<T>(string key)
{
    // Level 1: Check fast in-memory cache (e.g., IMemoryCache)
    if (_memoryCache.TryGetValue(key, out T value)) return value;

    // Level 2: Fallback to distributed Redis cache
    value = await _redisCache.GetAsync<T>(key);

    if (value != null)
    {
        // Back-propagate to L1 for faster subsequent hits
        _memoryCache.Set(key, value, TimeSpan.FromMinutes(1));
    }

    return value;
}

Operational Excellence in Redis

• Key Compression: Utilize binary serializers like MessagePack or Protobuf instead of JSON to reduce memory footprint and bandwidth.
• Monitoring: Keep a close watch on the keyspace_hits vs keyspace_misses ratio. A low hit rate might indicate that you are caching the wrong datasets.
• Eviction Policies: Ensure your Redis instance is configured with volatile-lru or allkeys-lru to prevent memory exhaustion by gracefully removing the least recently used keys.

Final Thoughts: Caching as a First-Class Citizen

Adding Redis to your stack shouldn’t be a reactive “patch” for slow queries. Instead, treat caching as a primary architectural component. By moving beyond basic “set and forget” patterns and implementing proactive invalidation and two-level strategies, you transform your cache from a source of potential inconsistency into a reliable performance accelerator. The goal isn’t just to make things faster, but to build a system that remains predictable under heavy load.

In recent years, microservices became the “default” choice for scaling applications, often prematurely. However, for many organizations, the operational overhead—service discovery, complex networking, and distributed tracing—outweighs the benefits. The Modular Monolith emerges as a superior middle ground, offering the logical separation of microservices with the deployment simplicity of a monolith.

Core Architectural Principles

A modular monolith is not just a “big ball of mud” structured as a single project. It requires strict boundary enforcement between domain modules.

1. Strict Bound Contexts: Each module represents a distinct domain (e.g., Ordering, Shipping, Catalog) and owns its data and business logic.
2. Encapsulation: Modules should communicate through restricted interfaces or internal message buses (e.g., MediatR), never by directly accessing another module’s private implementation or database tables.
3. Physical Separation: Initially implemented as separate projects or namespaces, facilitating a future transition to microservices if actually required.

Implementation Strategy in .NET

Utilizing the Clean Architecture pattern within each module ensures that business logic remains decoupled from external dependencies.

// Example: Cross-module communication via Internal Events
public class OrderCreatedHandler : INotificationHandler<OrderCreatedEvent>
{
    private readonly IShippingService _shippingService;

    public async Task Handle(OrderCreatedEvent notification, CancellationToken ct)
    {
        // One module reacts to another without direct coupling
        await _shippingService.ScheduleDelivery(notification.OrderId);
    }
}

Strategic Advantages

• Deployment Simplicity: A single CI/CD pipeline and runtime environment.
• Reduced Latency: Cross-component calls are in-process rather than over HTTP or gRPC.
• Easier Refactoring: Changing boundaries is significantly simpler within a single codebase than across multiple repositories.

Choosing Architecture with Intent

In the end, software architecture isn’t about following the flashiest trends; it’s about managing cognitive load and maintaining a sustainable development pace. A modular monolith allows you to grow your domain logic with the same rigor as microservices, but without the tax of distributed systems complexity. It’s an investment in your team’s productivity, ensuring that when you finally do need to extract a service, you’re doing so from a foundation of structured, decoupled logic rather than a messy entanglement.

In the modern DevOps landscape, containerization has transitioned from an optional optimization to a fundamental requirement. Docker provides a standardized environment that ensures your .NET Core applications run consistently across development, staging, and production boundaries, eliminating the “it works on my machine” paradigm.

Foundational Infrastructure: Environment Configuration

While Docker supports cross-platform execution, implementing your containerization pipeline on a Linux-based architecture (e.g., Ubuntu 20.04) often yields the most predictable results and optimal performance.

Installation Pipeline:

# Updating package indices and installing the Docker engine
sudo apt-get update && sudo apt-get install -y docker.io

# Verification of successful deployment
docker -v

Architecting the Container Blueprint: The Multi-Stage Dockerfile

A high-efficiency Dockerfile utilizes multi-stage builds to minimize image size and maximize security by separating the build environment from the runtime environment.

# Stage 1: Runtime Base
FROM mcr.microsoft.com/dotnet/core/runtime:3.1 AS base
WORKDIR /app

# Stage 2: Compilation and Build
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY ["SimplisticApi.csproj", "./"]
RUN dotnet restore "./SimplisticApi.csproj"
COPY . .
RUN dotnet build "SimplisticApi.csproj" -c Release -o /app/build

# Stage 3: Artifact Publication
FROM build AS publish
RUN dotnet publish "SimplisticApi.csproj" -c Release -o /app/publish

# Stage 4: Final Production Image
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "SimplisticApi.dll"]

Image Orchestration and Local Verification

Once the blueprint is defined, you can build and execute the containerized application locally.

# Building the immutable image
docker build -t net-core-app:v1 .

# Executing the containerized environment
docker run net-core-app:v1

Global Distribution via Docker Hub

To facilitate remote deployment and team collaboration, leverage Docker Hub as your centralized image registry.

1. Authentication: Authenticate your local daemon with the docker login command.
2. Tagging: Align your local image name with your Huber username (e.g., username/app-name:tag).
3. Transmission: Push the finalized image to the global registry.

# Naming for distribution
docker tag net-core-app:v1 username/professional-net-app:v1

# Transmitting to the registry
docker push username/professional-net-app:v1

Strategic Advantages of Containerization

• Isolation: Ensures application dependencies do not conflict with the host OS or other containers.
• Scalability: Facilitates rapid horizontal scaling via orchestrators like Kubernetes or Docker Swarm.
• Portability: Single-artifact deployment across any infrastructure that supports the Docker runtime.

Deep Dive: Explore the comprehensive containerization lifecycle and advanced CI/CD integration patterns on GitHub.

GitHub recently introduced a transformative feature for developer discoverability: the Profile README. This allows developers to showcase their technical expertise, ongoing contributions, and personal branding directly on their primary GitHub landing page, moving beyond the traditional list of pinned repositories.

Orchestrating the “Secret” Repository

To activate this feature, you must create a specialized repository that acts as a global profile configuration.

1. Identity Alignment: Create a new repository where the repository name matches your GitHub username exactly (e.g., username/username).
2. Visibility: The repository must be configured as Public.
3. Initialization: Ensure you include a README.md file during the creation process.

Designing the Profile Landscape

GitHub provides a specialized template upon repository initialization, which serves as a foundation for your profile’s narrative.

Strategic Best Practices for Profile Design

• Dynamic Content: Integrate GitHub Actions to dynamically update your profile with latest blog posts, Spotify activity, or contribution statistics.
• Visual Impact: Utilize markdown-supported badges (e.g., Shields.io) to display your technical stack graphically.
• Accessibility: Ensure your profile remains scannable and accessible across both light and dark GitHub themes.
• Iterative Design: Leverage specialized markdown editors like StackEdit to preview and refine your layout before pushing to production.

By treating your GitHub profile as an evolving technical portfolio, you can significantly enhance your visibility within the global engineering community.

A JSON Web Token (JWT) is a standardized, compact method (RFC 7519) for securely transmitting information as a JSON object. In modern distributed systems, JWTs are the preferred mechanism for stateless authentication, allowing services to verify user identity without maintaining localized session state.

Anatomy of a JWT

A JWT is a base64url encoded string consisting of three cryptographically bound segments:

1. Header: Defines the signing algorithm (e.g., HS256) and token type.
2. Payload: Contains Claims—assertions about the user (e.g., ID, Role, Email) and technical metadata like expiration (exp).
3. Signature: A cryptographic hash of the header and payload, generated using a server-side secret key to ensure data integrity.

Strategic Implementation: Generating Secure Tokens

The following implementation demonstrates how to orchestrate a login workflow that validates credentials and issues a signed JWT.

[AllowAnonymous]
[HttpPost("authenticate")]
public ActionResult<AuthResponse> Login([FromBody] LoginRequest request)
{
    using (var context = new ApplicationDbContext())
    {
        var user = context.Users.SingleOrDefault(u => u.Email == request.Email);
        if (user != null && CryptoUtility.VerifySecureHash(request.Password, user.Salt, user.HashedPassword))
        {
            var tokenHandler = new JwtSecurityTokenHandler();
            var key = Encoding.ASCII.GetBytes(_config["Jwt:Secret"]);

            var tokenDescriptor = new SecurityTokenDescriptor
            {
                Subject = new ClaimsIdentity(new[] {
                    new Claim(ClaimTypes.Name, user.Email),
                    new Claim(ClaimTypes.Role, user.Role)
                }),
                Expires = DateTime.UtcNow.AddHours(2),
                SigningCredentials = new SigningCredentials(new SymmetricSecurityKey(key), SecurityAlgorithms.HmacSha256Signature)
            };

            var token = tokenHandler.CreateToken(tokenDescriptor);
            return Ok(new AuthResponse { Token = tokenHandler.WriteToken(token) });
        }
    }
    return Unauthorized("Authentication failed: Invalid credentials.");
}

Credential Hardening: Salted Hashing in .NET

Raw SHA-based hashing is insufficient against modern dictionary and rainbow table attacks. We implement a robust defense by generating a unique, cryptographically random Salt for every user and executing iterative hashing.

public static class CryptoUtility
{
    public static string GenerateSalt() => Guid.NewGuid().ToString("N");

    public static string ComputeIterativeHash(string password, string salt)
    {
        var hash = password + salt;
        for (int i = 0; i < 10000; i++) // Standard iteration count for computational cost
        {
            hash = BitConverter.ToString(SHA512.Create().ComputeHash(Encoding.UTF8.GetBytes(hash)));
        }
        return hash;
    }
}

Configuring the Middleware Pipeline

In the .NET Core startup sequence, we inject the authentication handlers to intercept and validate incoming Bearer tokens.

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(x => {
        x.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
        x.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
    }).AddJwtBearer(x => {
        x.RequireHttpsMetadata = true;
        x.SaveToken = true;
        x.TokenValidationParameters = new TokenValidationParameters {
            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.ASCII.GetBytes(Configuration["Jwt:Secret"])),
            ValidateIssuer = false,
            ValidateAudience = false
        };
    });
}

Data Persistence: MySQL Integration

For high-performance data storage, MySQL is utilized via the Pomelo.EntityFrameworkCore.MySql provider, facilitating seamless EF Core migrations and strongly-typed queries.

-- Optimized User Schema
CREATE TABLE `Users` (
  `Id` int NOT NULL AUTO_INCREMENT,
  `Email` varchar(255) NOT NULL,
  `Salt` char(32) NOT NULL,
  `HashedPassword` varchar(512) NOT NULL,
  `Role` varchar(50) DEFAULT 'User',
  PRIMARY KEY (`Id`),
  UNIQUE KEY `Email_UNIQUE` (`Email`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Advanced Security Best Practices

1. Secret Rotation: Never hard-code your secret keys. Utilize environment variables or Azure Key Vault.
2. HTTPS Enforcement: JWTs are susceptible to man-in-the-middle attacks if transmitted over unencrypted channels.
3. Claims Sensitivity: Do not include sensitive information (like passwords or PII) in the JWT payload, as it is easily decoded by third parties.

Deep Dive: Explore the full source code and database migrations on GitHub.

Swagger UI is a sophisticated display framework that consumes an OpenAPI specification (formerly known as Swagger) and dynamically generates a beautiful, interactive documentation suite. Unlike static documentation, Swagger UI identifies the live endpoints of your ASP.NET Web API and provides a sandbox environment for real-time interaction.

Why Swagger UI? Efficiency and Discoverability

Traditional ASP.NET Help Pages are often static and lack the capability for direct browser-based interaction. Swagger UI bridges this gap by offering several strategic advantages:

• Interactive Sandbox: Consumers can execute API calls directly from the browser without third-party tools like Postman.
• Client Decoupling: Facilitates frictionless collaboration between back-end and front-end teams by providing a “source of truth” for endpoint contracts.
• Discovery: Automatically documents data models (DTOs), enumerations, and HTTP status codes.

Installation via NuGet

The most streamlined way to integrate Swagger into a .NET project is via the Swashbuckle package.

Install-Package Swashbuckle

Configuration Strategy

Upon installation, a SwaggerConfig.cs file is added to the App_Start directory. This file utilizes a PreApplicationStartMethod attribute to register the Swagger engine during the OWIN/IIS startup sequence.

[assembly: PreApplicationStartMethod(typeof(SwaggerConfig), "RegisterSwaggerConfig")]

namespace ProfessionalApi.App_Start
{
    public class SwaggerConfig
    {
        public static void RegisterSwaggerConfig()
        {
            GlobalConfiguration.Configuration
                .EnableSwagger(c => {
                    c.SingleApiVersion("v1", "Enterprise Notes API");
                    c.IncludeXmlComments(GetXmlCommentsPath()); // Include XML comments for deeper context
                })
                .EnableSwaggerUi(c => {
                    c.DocumentTitle("Notes API Documentation");
                });
        }
    }
}

Accessing the Documentation

Once deployed, the interactive interface is accessible via the /swagger endpoint.

Strategic Best Practices

1. XML Documentation: Enable XML documentation file generation in your project settings to allow Swagger to pull in your <summary> and <param> comments into the UI.
2. Security Schemes: Configure Swagger to support OAuth 2.0 or Bearer Token headers so that developers can test protected endpoints.
3. Production Hardening: Ensure Swagger is only enabled in development or staging environments to prevent exposing internal infrastructure details in production.

Technical Artifacts: The complete integration pattern and configuration scripts are available for review on GitHub.