How Step2Dev Handles Multi-Project DevOps: The Technical Design

I am building in public, so I want to share the actual technical decisions behind Step2Dev's multi-project architecture. This is how we handle the core challenge: multiple projects, multiple AWS accounts, one consistent experience.

## The Problem We Are Solving

A DevOps engineer managing 5 projects across 3 AWS accounts today uses:

• Multiple browser sessions for different AWS accounts
• Different pipeline configurations stored in different repositories
• Separate monitoring dashboards per account
• Mental overhead to track which account/project/environment they are currently in

The tools are not connected. The engineer's brain is the connection layer.

## Design Principle 1: The Project Is the Abstraction

In Step2Dev, the "project" is the top-level concept. Not the AWS account. Not the region. Not the environment.

A project contains: its AWS account connections, its environments (dev, staging, prod), its services, its pipelines, its monitoring configuration.

The engineer thinks in terms of projects. The platform handles the AWS account switching transparently.

## Design Principle 2: AWS Account Connection Without Credential Storage

This was the most important security decision we made.

We do NOT store AWS access keys. Instead, users create an IAM role in each AWS account they want to connect. That role has a trust policy that allows Step2Dev's role to assume it using AWS Security Token Service (STS).

When Step2Dev needs to perform an action in a user's AWS account, it calls sts:AssumeRole to get temporary credentials (valid for 1 hour maximum), uses those credentials to perform the action, and the temporary credentials expire automatically.

The user retains full control. They can revoke our access by modifying or deleting the IAM role. We have no persistent credentials to compromise.

 User's AWS Account
 └── IAM Role: Step2DevConnector
  ├── Trust Policy: allows Step2Dev service to assume this role
  ├── Permissions: scoped to what Step2Dev needs
  └── Revocable: user can delete this role at any time

## Design Principle 3: Project Templates for Repeatable Setup

The most universally reported pain point in user research: setting up a new project from scratch.

Step2Dev stores project templates that define the infrastructure, pipeline, and monitoring configuration for a project type. When you create a new project, you select a template, and the platform provisions everything consistently.

Templates are stored as code (Terraform modules + pipeline definitions), versioned, and user-customizable. You can create your own templates from existing projects.

## Design Principle 4: Unified Monitoring Across All Accounts

CloudWatch metrics are account-scoped. To see metrics across multiple accounts natively, you need CloudWatch cross-account observability, which requires setup in each account.

Step2Dev collects metrics from all connected accounts and presents them in a unified view. The engineer sees all their projects' health in one place, regardless of which AWS account the service is running in.

## The Technical Stack (Being Transparent)

• Backend: Node.js with TypeScript
• AWS SDK: v3 (modular, better tree-shaking)
• IAM role assumption: via STS with session tags for audit trails
• State management: PostgreSQL for project/account configurations
• Metric aggregation: pull-based, scheduled collection from CloudWatch APIs
• Frontend: React with TypeScript

## What I Got Wrong and Rebuilt

The first version used a push-based metric aggregation model (CloudWatch events streaming to our system). This was architecturally elegant but operationally complex to maintain. I rebuilt it as a pull-based model with scheduled collection. Less elegant, more reliable, easier to debug.

## What Is Coming Next

Server management: SSH-based server configuration and package management through a unified interface. Audited, logged, and reversible where possible.

The goal throughout: reduce the number of places an engineer has to go to understand and manage their infrastructure.

Questions about the technical decisions? I read every comment.