Building a Modular Automation Marketplace in HomeForged: How We Scaled ForgeKit Reusability

The Problem: Automation Sprawl Was Killing Developer Flow

A few months ago, our internal teams were drowning in automation scripts. Everyone had their own version of a CI pipeline, a deployment hook, or a database seeding routine—each written in slightly different ways, scattered across repos, and rarely shared. We called it ‘automation sprawl.’ The worst part? Every new project meant reinventing the wheel, often poorly. We needed a way to standardize, share, and scale automation logic without forcing teams into rigid templates.

That’s when we started building the HomeForged marketplace—a self-serve portal where developers could discover, configure, and deploy pre-built automation units called ForgeKits. The goal wasn’t just reuse; it was composable reuse. We wanted a developer to be able to pick a CI/CD ForgeKit, mix in a monitoring snippet, and plug in a custom deployment script—all without touching a config file.

Architecture: How the Marketplace and ForgeKits Work Together

The marketplace isn’t a separate app. It’s a Laravel-powered module inside HomeForged that dynamically loads ForgeKits as discoverable, versioned packages. Each ForgeKit is a self-contained directory with metadata, a schema, and executable scripts. Think of it like Laravel packages, but focused purely on automation workflows—things like environment setup, deployment pipelines, or audit logging.

On the frontend, we built a React-based automation portal that queries a registry endpoint. This endpoint scans registered ForgeKit directories (via service provider discovery) and returns JSON manifests describing each kit’s:

• Name, description, and version
• Input schema (for dynamic form rendering)
• Required permissions
• Preview of generated files or commands

When a user selects a ForgeKit, the portal renders a configuration form based on the schema. Once submitted, it sends the payload to a /forgekit/instantiate endpoint, which triggers a server-side artisan command under the hood. This command handles the actual scaffolding: file generation, variable injection, and dependency registration.

The real win was making this flow feel native. We didn’t want developers to context-switch between the web UI and the CLI. So we ensured every action in the portal maps 1:1 with an equivalent artisan make:forgekit command. That way, power users can script their own setups, while newcomers get guided workflows.

Fixing artisan make to Enable Dynamic ForgeKit Scaffolding

Early on, we hit a wall: our artisan make:forgekit command worked fine for built-in kits, but failed when dealing with third-party or dynamically registered ones. The issue? The command was hardcoded to look in a single directory and couldn’t resolve kits by ID or namespace.

After digging into the service container and Laravel’s command resolution, we realized we needed a registry pattern. We introduced a ForgeKitManager class that acts as a central broker—registering kits at boot time via service providers and resolving them by slug during execution.

Here’s the fix in action:

// In each ForgeKit's service provider
public function register()
{
    $this->app->make(ForgeKitManager::class)->register(
        'deploy-aws-lambda',
        base_path('forgekits/deploy-aws-lambda')
    );
}

Then, in the artisan command:

$kit = $this->manager->find($this->argument('kit'));
$this->callSilent('make:stub', [
    '--source' => $kit->getPath().'/stubs',
    '--dest' => $this->ask('Where should we scaffold this?'),
    '--vars' => $this->gatherFormInputs()
]);

This change unblocked dynamic scaffolding from both the CLI and the web portal. Now, when a user clicks “Deploy” in the marketplace, it’s not just a file copy—it’s a full artisan make invocation with validated inputs, executed securely in the background.

The result? We’ve seen a 70% reduction in boilerplate setup time across teams, and 15 new ForgeKits contributed back to the marketplace in the last month. Modularity without friction isn’t just possible in Laravel—it’s achievable when you treat automation as a first-class, composable asset.

We’re open-sourcing the core ForgeKit spec soon. If you’re building internal dev platforms, hit me up—let’s stop rewriting the same scripts over and over.