Developer Guide
Creating a New Microservice on EDP
A step-by-step walkthrough of the Equinox Developer Platform — from template selection to automated GitHub & Terragrunt deployment.
Building Client-Specific Services on Equinox
Client-Specific Isolation
Each client gets a dedicated service with its own repository and infrastructure — changes for one client can never impact another.
Stub as a Ready Foundation
EDP doesn’t create an empty project — it creates a fully running stub service with health checks, logging, and CI/CD already configured.
Zero Risk to Production
New client work is isolated from day one. Existing live services for other clients are never touched or put at risk.
Faster Client Onboarding
Manual setup (repo, infra, CI/CD, environment wiring) that used to take days is completed by EDP in minutes.
Enforced Standards from Day One
Every stub inherits Equinox naming conventions, security baselines, and observability tooling — no manual configuration needed.
About This Guide
The Equinox Developer Platform (EDP) provides a self-service portal that automates the full lifecycle of microservice creation — from GitHub repository scaffolding to infrastructure provisioning and environment deployment via Terragrunt. This guide walks through the end-to-end flow using the Equinox Microservice Template. No infrastructure expertise is needed — the platform handles everything once you fill in a short form.
Prerequisites
Access to the EDP portal at
eq-dev-edp.eqcmrc.comMembership in GitHub org
Infosys-EquinoxTarget deployment environment provisioned (e.g.,
eq9-dev-dev2)Step-by-Step Flow
1
Access the EDP Portal
Open the Equinox Developer Platform in your browser. This is the single place where your team manages, creates, and monitors all microservices — like a control panel for your software.
Navigate to the EDP portal home page. The dashboard provides quick navigation to key platform capabilities.
| Action | Description |
|---|---|
| Browse Templates | Explore available service scaffolding templates |
| Explore Catalog | View all registered services and components |
| Create New Service | Shortcut to launch the creation wizard |
2
Browse & Select a Template
Instead of setting up a project from scratch, we pick a ready-made blueprint (template). The Equinox Microservice Template is the standard blueprint for all new services — it already knows how to create a GitHub project, set up the code structure, and connect to your cloud environment.
Click Create… in the left navigation or Create New Service from the Quick Actions panel. Select the Equinox Microservice Template (tagged as
service).
What this template does:
- Generates a templated service structure following predefined configurations and best practices
- Creates and publishes the repository to GitHub under the configured organization
- Triggers an embedded CI/CD workflow that automatically deploys the service to the designated environment
3
Fill in Required Details
Give your new service a name and tell the system where it should live. This is similar to filling out a form when opening a new account — the platform uses these details to create and register everything on your behalf.
The wizard prompts for two categories of information.
3a — Service Identity
| Field | Description | Example |
|---|---|---|
| Microservice Name | Unique name for the service | eq-demomicroservice |
| Owner | Team or individual accountable for the service | platform-team |
3b — Repository & Ownership
| Field | Description | Example |
|---|---|---|
| Host | Git hosting platform | github.com |
| Owner Available | GitHub organization | Infosys-Equinox |
| Repository | Repository name | eq-demo-microservice |
⚠️ Naming Rule: Repository names must start with
eq-, be 4–100 characters total, and may contain letters, numbers, hyphens, underscores, and periods after the prefix.
4
Select Required AWS Resources
Tick the boxes for the cloud building blocks your service needs — like a database to store data, a cache to make it faster, or a messaging bus to talk to other services. The platform sets all of these up automatically; you don’t need to configure them manually.
Check the AWS infrastructure resources your microservice needs. The platform provisions these automatically during deployment.
DocumentDB
Amazon DocumentDB
MySQL (RDS)
Amazon RDS
Redis
ElastiCache
Event Bridge
Amazon EventBridge
Cognito
Amazon Cognito
S3 Assets
Amazon S3
Environment Targeting
| Field | Description | Example |
|---|---|---|
| Target Environment | Primary deployment environment | resource:default/eq9-dev-dev2 |
| Promotion Environment | Optional. Auto-promote after primary succeeds | Leave blank to skip |
5
Review Configuration
Before anything is created, the portal shows you a summary of all your choices — like a checkout page before confirming an order. Take a moment to verify the service name, owner, and selected resources, then click CREATE to kick everything off.
Before creating, the wizard presents a full summary for confirmation. Verify all values before clicking CREATE.
| Owner | platform-team |
| Required Resources | document-db elasticache event-bridge |
| Repository & Ownership | github.com?owner=Infosys-Equinox&repo=eq-demo-microservice |
| Microservice Name | eq-demomicroservice |
| Target Environment | resource:default/eq9-dev-dev2 |
6
Automated Provisioning — What Happens Behind the Scenes
After you click CREATE, you can sit back — the platform takes over. It automatically creates a code repository on GitHub, provisions all the cloud infrastructure you selected, and deploys a running version of your service. What would normally take days of manual work completes in minutes.
Once you click CREATE, the platform executes three parallel automation tracks.
🐙
GitHub Repository Created
- Scaffolded with Equinox microservice boilerplate
- Branch protection rules applied
- CI/CD workflows pre-configured
🏗️
Infrastructure Provisioned via Terragrunt
- Requested AWS resources provisioned (DocumentDB, ElastiCache, EventBridge, etc.)
- IAM roles and secrets configured
- Environment-specific config injected
🚀
Service Deployed to Target Environment
- Container image built and pushed to registry
- Service registered in EDP catalog
- Optional: Promoted to secondary environment if configured
What the Generated Stub Contains
When EDP provisions your new service, it doesn’t create an empty folder — it creates a fully working, deployable stub. Here is exactly what lands in your GitHub repository from day one, ready to extend with client-specific logic.
📁
Repository Structure
📂 eq-<service-name>/
├─
index.js
Fastify app entry point
├─
package.json
dependencies & npm scripts
├─
Dockerfile
multi-stage container build
├─
openapi.yaml
OpenAPI / Swagger spec
├─
swagger.js
Swagger UI wiring
├─
db.js
database connection helper
├─
.env.example
environment variables template
├─
catalog-info.yaml
EDP catalog registration
├─
routes/
└─
hello.js
example API route
└─
.github/workflows/
└─
ci.yml
pre-configured CI/CD pipeline
🛠️ Technology Stack
Node.js 24
Fastify
Docker
GitHub Actions
OpenAPI
Jest
🔌 Built-in Endpoints
| Endpoint | Purpose |
|---|---|
GET /health | Is the service running? |
GET /ready | Ready for traffic? |
GET /<service>/documentation | Swagger UI |
🔄 CI/CD Pipeline Stages
📝
Lint
Code quality checks
🧪
Unit Tests
Jest test suite runs
🔒
Security Scan
Vulnerability check
🐳
Docker Build
Container image created
🚀
Deploy
Pushed to target environment
After Deployment — What You Can Do Next
Once the service is live, two powerful things are immediately available: a built-in API documentation page (Swagger) so anyone can explore and test the service’s capabilities, and an automated pipeline (GitHub Actions) that keeps the service up to date every time a developer pushes new code — no manual deployments needed.
Swagger API Documentation
Interactive API explorer — available immediately after deployment
Think of Swagger as a live instruction manual for your service. Anyone — developer, tester, or product manager — can open it in a browser, see every available API operation, and even try them out directly without writing any code.
- Auto-generated from the service’s code — always up to date
- Lists every endpoint with inputs, outputs, and response codes
- Allows you to send test requests and see real responses in the browser
- Shared with integration partners for faster onboarding
# Access Swagger UI after deployment # Example https://eq9-dev-dev2.eqcmrc.com/eq-demomicroservice/documentation
Continuous Deployment via GitHub Actions
Every code commit automatically triggers a new deployment
GitHub Actions is a robot that watches your code repository. The moment a developer pushes an approved change, the robot automatically tests, builds, and deploys the updated service — no one has to manually trigger anything.
Automated pipeline triggered on every commit to main:
📝 Code Push
→
🧪 Run Tests
→
🏗️ Build Image
→
🚀 Deploy
→
✅ Live
- Workflow files are pre-configured in the repository by the EDP template
- Failed tests automatically block the deployment — preventing broken code going live
- Deployment history and logs visible in the GitHub Actions tab
- Supports promotion to staging or production after dev succeeds
End-to-End Flow
Phase 1 — User Configuration
1
Open EDP Portal
›
2
Browse Templates
›
3
Select Microservice Template
›
4
Fill Service Details & Repo
›
5
Select AWS Resources
›
6
Review & Confirm
›
CREATE
triggers automated provisioning
Phase 2 — Automated Platform Provisioning
Track A — Code
GitHub Repository Created & Scaffolded
Track B — Infrastructure
Terragrunt Provisions AWS Infrastructure
CI/CD Pipeline Triggered Automatically
deployment complete
Phase 3 — Live Service & Continuous Delivery
Service Deployed & Registered in EDP Catalog
API Documentation
Swagger UI Live — Explore & Test APIs
Continuous Deployment
GitHub Actions Active
Any Commit → Auto Deploy
Key Benefits
Speed
Full service bootstrap in minutes, not days.
Consistency
All services follow the same structural conventions.
Reliability
Infrastructure-as-code via Terragrunt eliminates manual errors.
Traceability
Every resource is tracked and visible in the EDP catalog.
Self-Service
Teams create and deploy without platform team intervention.
Revision History
2026-08-10 | JP – Created the page and added the content.