GoVisaX — Go-Live Runbook · Production Launch Sequence

Pre-Flight

Pre-Flight Gates — Complete Before Touching Infrastructure

Every item below must be checked off before issuing the first cdk deploy command. Assign an owner to each item. Do not proceed if any item is unresolved.

🔴 BLOCKER: Visa2Fly B2B API Agreement Signed Navigate to b2b.visa2fly.com/signup → complete reseller registration → receive confirmation email with production API key + API secret. Without these credentials, the entire platform returns empty responses. SLA: allow 2–5 business days for Visa2Fly account approval.

BD Lead

🔴 BLOCKER: AWS Secrets Manager Populated with V2F Production Credentials Once credentials received from V2F: aws secretsmanager create-secret --name visa2fly/prod/api-key --secret-string "YOUR_KEY" --region ap-south-1 and aws secretsmanager create-secret --name visa2fly/prod/api-secret --secret-string "YOUR_SECRET" --region ap-south-1. Verify ECS task role has secretsmanager:GetSecretValue permission scoped to these two ARNs only.

DevOps

⚠️ ACM Wildcard Certificate Issued for *.govisax.com Certificate must be in us-east-1 (for CloudFront) AND ap-south-1 (for ALB). Confirm both are in ISSUED status. Required by InfraStack.ts at deploy time. Certificate ARN must be stored in cdk.context.json or passed as a parameter.

DevOps

⚠️ Route 53 Hosted Zone for govisax.com Exists Hosted zone ID required by CDK stack for DNS records (ALB alias, CloudFront distribution, MX records). Run aws route53 list-hosted-zones to confirm. If absent, create via console before CDK deploy.

DevOps

⚠️ Razorpay Production Keys Configured Store razorpay/prod/key-id and razorpay/prod/key-secret in AWS Secrets Manager. PaymentService.java reads these at startup. Test with Razorpay's test mode first; switch RAZORPAY_ENV=live in ECS task definition only after first successful test payment.

Backend Lead

⚠️ AWS SES Production Access Approved (Email Sending) By default, SES is in sandbox mode (emails only to verified addresses). Submit production access request in AWS console → approve domain govisax.com for sending. Required for NotificationService.java transactional emails. Allow 24–48h for AWS approval.

DevOps

ℹ️ PagerDuty Integration Key Configured Create a PagerDuty service → generate integration key → store as pagerduty/prod/integration-key in Secrets Manager. Required for CloudWatch alarm actions in Monitoring_GoLive.yml. Without this, alarms fire but no on-call engineer is paged.

DevOps

ℹ️ S3 Bucket Names Reserved and Unique S3 bucket names are global. Confirm govisax-documents-prod, govisax-logs-prod, and govisax-backups-prod are available. CDK will fail at deploy time if names are taken. Update bucket names in InfraStack.ts if needed.

DevOps

ℹ️ Phase 9 Canonical Mobile File Confirmed Delete GoVisaX_Phase9_PaymentUploadBookings.tsx (prior draft). Keep GoVisaX_Phase9_UploadPaymentScreens.tsx as canonical. Run eas build --platform all --profile production only after this is confirmed. App store credentials (App Store Connect + Google Play) must be pre-configured in EAS.

Mobile Lead

ℹ️ GitHub Repository & Secrets Configured for CI/CD Confirm these GitHub Actions secrets exist in the repo: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION=ap-south-1, ECR_REGISTRY, ECS_CLUSTER, ECS_SERVICE. Required by CICD_Pipeline.yml. The pipeline fails at Step 1 (AWS login) if any are missing.

DevOps

Step 1 of 10 · External Action · Critical Path

Sign Visa2Fly B2B API Agreement

This is the single external dependency that blocks every downstream step. No code can be altered to unblock this — Visa2Fly must issue the production keys. Initiate this immediately and in parallel with all internal pre-flight items.

1

Register at Visa2Fly B2B Portal

Owner: BD Lead · ETA: 2–5 business days for approval · Blocking: All subsequent steps

Action — Navigate to

https://b2b.visa2fly.com/signup

Registration Checklist

Company registration documents ready — GST certificate, PAN card, travel agency license (if applicable)

Complete the B2B reseller form — Select "API Integration / White-Label" as the use case. Specify expected monthly application volumes (use 1,000/month as initial estimate).

Sign the reseller agreement — Review markup restrictions, SLA terms, and data processing agreement (DPA). Legal team must review before signing.

Receive sandbox credentials — Verify sandbox integration works end-to-end using Visa2FlyApiClient.java with sandbox keys before requesting production keys.

Request production API key + secret — After sandbox verification, request production credentials. V2F will email these to the registered account holder.

⚠️

Important: The V2F sandbox API and production API use different base URLs and different authentication endpoints. Ensure application.yml has separate visa2fly.sandbox.base-url and visa2fly.production.base-url properties, and that the active profile (spring.profiles.active) switches correctly between them.

Step 2 of 10 · Infrastructure Prep · Critical Path

Populate AWS Secrets Manager

All production credentials are stored exclusively in AWS Secrets Manager. No secret appears in code, environment variables, Docker images, or logs. Execute these commands only after V2F production keys are received.

2

Store All Production Secrets

Owner: DevOps · ETA: 15 minutes · Region: ap-south-1

V2F Production Credentials (received from Visa2Fly)

$ aws secretsmanager create-secret \ --name visa2fly/prod/api-key \ --secret-string "PASTE_V2F_API_KEY_HERE" \ --region ap-south-1 \ --description "Visa2Fly B2B Production API Key" $ aws secretsmanager create-secret \ --name visa2fly/prod/api-secret \ --secret-string "PASTE_V2F_API_SECRET_HERE" \ --region ap-south-1 \ --description "Visa2Fly B2B Production API Secret"

Razorpay Payment Gateway

$ aws secretsmanager create-secret \ --name razorpay/prod/key-id \ --secret-string "rzp_live_XXXXXXXXXXXXXXX" \ --region ap-south-1 $ aws secretsmanager create-secret \ --name razorpay/prod/key-secret \ --secret-string "PASTE_RAZORPAY_SECRET" \ --region ap-south-1 $ aws secretsmanager create-secret \ --name razorpay/prod/webhook-secret \ --secret-string "PASTE_RAZORPAY_WEBHOOK_SECRET" \ --region ap-south-1

JWT Signing Key (generate a new 256-bit key)

$ openssl rand -base64 32 # Copy output — use as JWT secret below $ aws secretsmanager create-secret \ --name govisax/prod/jwt-secret \ --secret-string "PASTE_OPENSSL_OUTPUT_HERE" \ --region ap-south-1

PagerDuty + Monitoring

$ aws secretsmanager create-secret \ --name pagerduty/prod/integration-key \ --secret-string "PASTE_PAGERDUTY_KEY" \ --region ap-south-1

Verify all secrets are stored correctly

$ aws secretsmanager list-secrets \ --region ap-south-1 \ --query "SecretList[].Name" \ --output table # Expected output includes: # visa2fly/prod/api-key # visa2fly/prod/api-secret # razorpay/prod/key-id # razorpay/prod/key-secret # razorpay/prod/webhook-secret # govisax/prod/jwt-secret # pagerduty/prod/integration-key

🚫

Never do this: Do not paste V2F credentials into application.yml, .env files, Dockerfile, or GitHub Actions secrets. The ECS task role reads secrets at container startup via the secrets block in the task definition. Secrets in code = automatic SOC2 CC6.1 violation + potential V2F contract breach.

Step 3 of 10 · Infrastructure Deploy · ~25 minutes

Deploy AWS Infrastructure via CDK

InfraStack.ts provisions the full AWS stack in a single command: VPC, ECS Fargate cluster, RDS MySQL, ElastiCache Redis, S3 buckets, ALB, WAF, CloudFront, CloudWatch dashboards, and IAM roles.

3

Bootstrap CDK and Deploy Full Stack

Owner: DevOps · ETA: ~25 min · AWS Region: ap-south-1

1 — Install dependencies and bootstrap CDK (first time only)

$ cd infra/ $ npm install $ cdk bootstrap aws://ACCOUNT_ID/ap-south-1 # Only needed once per account/region

2 — Review what will be created (dry run)

$ cdk diff GoVisaX-Prod # Review all resources before committing. # Expected: VPC, 2×ECS Services, RDS, ElastiCache, 3×S3, ALB, WAF, CloudFront, CloudWatch

3 — Deploy (requires pre-flight items 3–8 complete)

$ cdk deploy GoVisaX-Prod \ --require-approval broadening \ --outputs-file cdk-outputs.json # Monitor progress in terminal — ~25 minutes # Key milestones printed by CDK: # ✅ GoVisaX-Prod | 1/42 | Creating VPC... # ✅ GoVisaX-Prod | 8/42 | Creating RDS MySQL cluster... # ✅ GoVisaX-Prod | 18/42 | Creating ECS Fargate service... # ✅ GoVisaX-Prod | 38/42 | Creating CloudWatch alarms... # ✅ GoVisaX-Prod | 42/42 | Deployment complete

4 — Capture output values for downstream steps

$ cat cdk-outputs.json # Note these values — needed for DNS and CI/CD: # GoVisaX-Prod.AlbDnsName = govisax-prod-xxx.ap-south-1.elb.amazonaws.com # GoVisaX-Prod.CloudFrontDomain = dxxxxxxxxxxxxx.cloudfront.net # GoVisaX-Prod.EcrRepositoryUri = ACCOUNT.dkr.ecr.ap-south-1.amazonaws.com/govisax # GoVisaX-Prod.EcsClusterName = GoVisaX-Prod-Cluster # GoVisaX-Prod.EcsServiceName = GoVisaX-Prod-Service # GoVisaX-Prod.RdsEndpoint = govisax-prod.xxx.ap-south-1.rds.amazonaws.com

⚠️

RDS First-Run Migration: After CDK deploy, the RDS MySQL instance is empty. Run MySQL_Schema.sql against the production endpoint before the first ECS container starts: mysql -h ENDPOINT -u admin -p govisax_prod < MySQL_Schema.sql. ECS health checks will fail until the schema is present.

🔴 Rollback — If CDK Deploy Fails

$ cdk destroy GoVisaX-Prod --force # CDK will tear down all resources it created. # S3 buckets with content must be emptied first: $ aws s3 rm s3://govisax-documents-prod --recursive # Fix the error in InfraStack.ts, then re-run cdk deploy.

Step 4 of 10 · DNS Configuration · ~5 minutes + propagation

DNS Cutover — Route 53

Point all GoVisaX domains to the newly deployed infrastructure. DNS propagation takes 0–5 minutes with Route 53 alias records (no TTL delay for alias A records to AWS resources).

4

Configure Route 53 Alias Records

Owner: DevOps · ETA: 5 minutes + propagation · Use values from cdk-outputs.json

Domain	Type	Target	Purpose
`govisax.com`	A (Alias)	CloudFront Distribution	Main customer-facing website
`www.govisax.com`	A (Alias)	CloudFront Distribution	WWW redirect
`api.govisax.com`	A (Alias)	ALB DNS Name	Backend API (internal + partner)
`sandbox.govisax.com`	A (Alias)	Sandbox ALB DNS Name	Developer sandbox environment
`admin.govisax.com`	A (Alias)	ALB DNS Name	Internal admin portal (WAF IP-restricted)
`pay.govisax.com`	A (Alias)	Razorpay payment page (CNAME)	Payment link redirection
`docs.govisax.com`	A (Alias)	CloudFront (developer portal)	Developer API documentation

Verify DNS propagation after records are set

$ dig +short api.govisax.com # Should resolve to ALB IPs within 2–5 minutes $ curl -s https://api.govisax.com/partner/v1/utils/status # Expected: # {"status":"operational","version":"1.0.0","latency_ms":12} $ curl -s -I https://govisax.com # Expected: HTTP/2 200 with X-Frame-Options, Strict-Transport-Security headers

Step 5 of 10 · Application Deployment · ~8 minutes

Trigger CI/CD Pipeline — Build & Deploy Application

The 7-stage GitHub Actions pipeline (CICD_Pipeline.yml) builds the Docker image, runs unit tests, executes the mandatory white-label scan gate, pushes to ECR, and deploys to ECS Fargate using blue-green deployment. Zero-downtime guaranteed.

5

Push to main → Auto-Deploy via GitHub Actions

Owner: Backend Lead · ETA: ~8 min · Triggered by: git push to main

Trigger the pipeline

$ git checkout main $ git pull origin main $ git tag v1.0.0-prod -m "GoVisaX Production Launch v1.0.0" $ git push origin main --tags # GitHub Actions pipeline auto-triggers on push to main # Monitor at: github.com/your-org/govisax/actions

7-Stage Pipeline Execution — What to Watch

Stage	Name	Action	Pass Condition	Fail Action
1	AWS Login	Configure AWS credentials from GitHub secrets	Exit code 0	Check GitHub secret values
2	Unit Tests	Run `TestSuites.java` (JUnit 5)	0 test failures	Fix failing tests; re-push
3	WL Scan Gate	Grep compiled output & configs for "visa2fly" string	Zero matches	Pipeline fails; no deploy. Find & remove the reference.
4	Docker Build	Build image, tag with git SHA + `latest`	Image builds without error	Fix Dockerfile; check base image availability
5	ECR Push	Push image to ECR repository	Image visible in ECR	Check ECR permissions on IAM role
6	ECS Deploy	Register new task definition; trigger blue-green CodeDeploy	ECS service stabilised with new task	Check ECS service events; review task logs in CloudWatch
7	Smoke Test	`curl https://api.govisax.com/partner/v1/utils/status`	HTTP 200 + `"status":"operational"`	Trigger blue-green rollback (Step 6 auto-rollback)

🔴 Rollback — If ECS Deploy Fails (Stage 6)

# Blue-green CodeDeploy auto-rolls back on health check failure. # To manually force rollback to previous task definition: $ aws ecs update-service \ --cluster GoVisaX-Prod-Cluster \ --service GoVisaX-Prod-Service \ --task-definition govisax-prod:PREVIOUS_REVISION \ --region ap-south-1 # Get previous revision number: $ aws ecs list-task-definitions \ --family-prefix govisax-prod \ --sort DESC \ --max-items 5

Step 6 of 10 · Compliance Verification · Runs inside CI/CD

White-Label Scan Gate — Verify Zero V2F Exposure

The white-label scan gate runs automatically as Stage 3 of the CI/CD pipeline. It can also be run manually at any time. A single match of the string visa2fly (case-insensitive) in any compiled output or configuration file fails the entire deployment.

6

Manual White-Label Scan (run on demand)

Owner: Any engineer · Can run locally or in CI

Run full scan against compiled output and configs

$ grep -ri "visa2fly" \ src/ \ target/ \ public/ \ dist/ \ --include="*.java" \ --include="*.ts" \ --include="*.tsx" \ --include="*.js" \ --include="*.yml" \ --include="*.yaml" \ --include="*.json" \ --include="*.html" \ --include="*.properties" # If no output: ✅ PASS — deploy can proceed # Any output: 🚫 FAIL — deployment must be blocked

Scan Docker image layers (post-build)

$ docker save govisax:latest | tar xO | strings | grep -i "visa2fly" # Should produce zero output

Scan live API responses (post-deploy — production smoke)

$ curl -s https://api.govisax.com/partner/v1/countries \ -H "Authorization: Bearer $TOKEN" | grep -i "visa2fly" $ curl -s https://api.govisax.com/partner/v1/visa/applications \ -H "Authorization: Bearer $TOKEN" | grep -i "visa2fly" # Both must return empty (no matches). # If any match: immediately invoke rollback procedure from Step 5.

8 White-Label Controls — Final Status

Control ID	Description	Enforcement	Status
WL-1	GoVisaX booking IDs only (GVXB-/GVXO-OTB-/GVXI-)	ApplicationService.java	Code Complete
WL-2	Response middleware strips all `visa2fly_*` fields	Visa2FlyApiClient.java	Code Complete
WL-3	PDFBox post-processor removes V2F branding from visa PDFs	PdfPostProcessingService.java	Code Complete
WL-4	CI/CD scan gate — blocks deploy on any V2F string match	CICD_Pipeline.yml Stage 3	Code Complete
WL-5	Developer portal contains zero V2F references	DeveloperPortal.tsx	Code Complete
WL-6	Error messages use GoVisaX-neutral language only	All controllers	Code Complete
WL-7	Admin V2F refs behind explicit toggle + clipboard disabled	AdminPortal.tsx	Code Complete
WL-8	k6 load test runtime assertion: `white_label_violations == 0`	GoVisaX_Phase15_LoadTest.js	Code Complete

Step 7 of 10 · Performance Validation · ~35 minutes

k6 Load Testing — Validate Performance at Scale

Run the 6-scenario k6 suite against production before any user traffic is admitted. The white-label violation counter is the most critical metric — a single hit triggers immediate rollback regardless of all other results.

7

Execute k6 Load Test Suite Against Production

Owner: QA Lead · ETA: ~35 min total (all 6 scenarios) · Tool: k6 v0.50+

Install k6 (if not already installed)

# macOS $ brew install k6 # Ubuntu/Debian $ sudo gpg -k && sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69 $ echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list && sudo apt-get update && sudo apt-get install k6

Run smoke scenario first (1 VU × 30s — fastest validation)

$ k6 run \ --env ENV=production \ --env API_KEY=$GVX_API_KEY \ --env API_SECRET=$GVX_API_SECRET \ --scenario smoke \ GoVisaX_Phase15_LoadTest.js # If smoke PASSES, run the full suite:

Run full suite (all 6 scenarios)

$ k6 run \ --env ENV=production \ --env API_KEY=$GVX_API_KEY \ --env API_SECRET=$GVX_API_SECRET \ --out json=k6-results.json \ GoVisaX_Phase15_LoadTest.js

Pass/Fail Thresholds

white_label_violations

Must equal exactly 0

IMMEDIATE ROLLBACK if > 0

auth_failures (401 count)

Must equal exactly 0

Check JWT config + Secrets Manager

http_req_duration p(95)

< 800ms

Investigate if >800ms; check DB indexes

http_req_failed (error rate)

< 1%

Check ECS task logs in CloudWatch

rate_limit_hits (429 rate)

< 5%

Expected during spike scenario; review Bucket4j config

token_refreshes

Should be > 0 (proves auto-refresh works)

If 0 during long soak: check SDK refresh timer

Step 8 of 10 · Monitoring & Alerting · Before user traffic

Activate Monitoring & CloudWatch Alarms

All CloudWatch alarms defined in Monitoring_GoLive.yml are deployed by CDK. Confirm they are in OK state before opening traffic. PagerDuty on-call rotation must be active for the 48-hour soft launch window.

8

Verify Alarms, Dashboard & On-Call Rotation

Owner: DevOps · ETA: 10 minutes · Must be done before Step 9

Confirm all alarms are in OK state (not ALARM or INSUFFICIENT_DATA)

$ aws cloudwatch describe-alarms \ --alarm-name-prefix "GoVisaX-Prod" \ --state-value ALARM \ --region ap-south-1 \ --query "MetricAlarms[].AlarmName" # Expected: empty array [] — no alarms currently firing $ aws cloudwatch describe-alarms \ --alarm-name-prefix "GoVisaX-Prod" \ --state-value INSUFFICIENT_DATA \ --region ap-south-1 \ --query "MetricAlarms[].AlarmName" # Expected: empty array [] (INSUFFICIENT_DATA = no data yet = alarm not yet warmed up) # A few minutes of traffic will move these to OK state automatically

Critical CloudWatch Alarms to Monitor During Launch

GoVisaX-Prod-API-5XX-Rate

Threshold: >1% 5xx errors over 5 min

Pages on-call immediately

GoVisaX-Prod-ECS-TaskStopped

Any ECS task in STOPPED state

Pages on-call; check task exit code

GoVisaX-Prod-V2F-Circuit-Open

Resilience4j circuit OPEN (V2F API down)

Pages on-call; check V2F status page

GoVisaX-Prod-RDS-CPU

>80% CPU for 10 minutes

Warning; investigate slow queries

GoVisaX-Prod-API-Latency-P95

p95 >1000ms over 5 min

Warning; check ECS CPU, DB connections

GoVisaX-Prod-Redis-Memory

>85% ElastiCache memory used

Warning; review TTL strategy

GoVisaX-Prod-HealthCheck

ALB target group healthy count

Alert if healthy count drops to 0

Step 9 of 10 · Controlled Release · 48-Hour Window

Soft Launch — 100 Beta Users, 48-Hour Monitoring Window

Admit a small cohort of pre-registered beta users before opening to the public. This limits blast radius if a production issue surfaces that was not caught in testing. Run full E2E transactions, not just health checks.

9

Beta Cohort Launch + 48h Monitoring

Owner: Product + DevOps · Duration: 48 hours · Cohort: 100 pre-registered users

Soft Launch Checklist

Enable beta user access — Flip feature.beta_access_enabled=true in admin pricing config. Beta users have pre-registered email addresses; admit via allow-list in ApplicationController.java.

Backend Lead

Complete end-to-end test transaction — Submit a real visa application (Dubai Tourist, ₹7,400) using a real passport. Verify: payment → S3 document upload → V2F processing → PDF post-processing → customer email delivery → zero V2F refs in delivered PDF.

QA Lead

Test sub-agent portal — Log in as a Bronze-tier agent → place booking → verify commission is calculated and wallet is credited. Test auto-upgrade trigger at booking threshold.

QA Lead

Test mobile app — Submit OTP login → complete visa application → upload passport photo → confirm push notification received on visa approval.

Mobile Lead

Test Partner API with real credentials — Issue a Starter-tier partner API key from AdminPortal → authenticate → call /visa/applications → verify GVXB- booking ID returned with zero V2F refs.

Backend Lead

48-hour CloudWatch watch period — DevOps on-call monitors the CloudWatch dashboard and PagerDuty rotation continuously. No alarms must fire unresolved for >15 minutes.

DevOps

Mobile app store submissions — Run eas build --platform all --profile production → submit iOS build to App Store Connect (TestFlight → App Review) and Android to Google Play Console (Internal Track → Production). App store review takes 1–3 days; initiate in parallel with soft launch.

Mobile Lead

✅

Go/No-Go Decision Point: After 48 hours — if zero P1 incidents, zero white-label violations, p95 latency under 800ms, and error rate under 0.5% → approve public launch. If any P1 incident occurred → hold and resolve before proceeding to Step 10.

Step 10 of 10 · Public Launch

Full Public Launch

Once the Go/No-Go decision is approved after the 48-hour soft launch window, flip the final switches and open GoVisaX to all traffic.

10

Open Platform to Public Traffic

Owner: Product Lead + DevOps · Gated on: Step 9 Go/No-Go approval

Remove beta allow-list restriction (AdminPortal or config update)

# In admin portal: Settings → Feature Flags # Set: feature.beta_access_enabled = false # Set: feature.public_access_enabled = true # OR via application config update + ECS rolling deploy: $ aws ecs update-service \ --cluster GoVisaX-Prod-Cluster \ --service GoVisaX-Prod-Service \ --force-new-deployment \ --region ap-south-1

Enable Razorpay live mode (switch from test to production)

# Update ECS task definition environment variable: # RAZORPAY_ENV=live (was: test during soft launch) # Trigger a new ECS deploy after this change.

Scale ECS service to production capacity

$ aws application-autoscaling put-scaling-policy \ --service-namespace ecs \ --scalable-dimension ecs:service:DesiredCount \ --resource-id service/GoVisaX-Prod-Cluster/GoVisaX-Prod-Service \ --policy-type TargetTrackingScaling \ --target-tracking-scaling-policy-configuration file://autoscaling-policy.json # autoscaling-policy.json: TargetValue=70 (CPU%), min=2 tasks, max=20 tasks

Post-Launch First 24 Hours — Key Metrics to Watch

📊

Business KPIs

Applications submitted · Payment success rate · Visa approval rate · Average processing time · Country breakdown

⚡

Infrastructure KPIs

ECS CPU/memory · RDS connections · Redis hit rate · ALB request count · p95 response time

🛡️

Compliance KPIs

White-label violations (must stay 0) · Failed auth attempts · WAF blocked requests · SOC2 audit event count

🚀

GoVisaX is Live

The GoVisaX × Visa2Fly white-label platform is in production. 53 files across 15 phases — fully deployed, monitored, and open to the world. Visa2Fly remains completely invisible at every customer touchpoint.

53

Files Deployed

8

WL Controls Active

23

Countries Available

4

Partner SDKs Live

₹99

Min Margin Floor

Appendix A

Incident Response — Severity Levels & Response Procedures

Use this table during the 48-hour soft launch window and post-launch. Every P1 incident must be declared immediately and the rollback procedure initiated if the root cause cannot be identified within 15 minutes.

Severity	Definition	Response Time	Owner	Escalation
P1 — Critical	White-label violation detected in live API · Platform completely down · Payment processing failure · V2F circuit breaker open for >5 min	Immediate — rollback within 15 min	DevOps On-Call	CTO + BD Lead + Legal (if V2F exposure confirmed)
P2 — High	5xx error rate >1% · ECS task crashes · p95 latency >2s · Single product line down (Visa/OTB/Insurance)	Within 30 minutes	Backend Lead	DevOps + Product Lead
P3 — Medium	Single country processing delayed · Non-critical feature broken · Mobile push notification failures	Within 4 hours	Backend Lead	Product Lead
P4 — Low	UI cosmetic issue · Non-critical analytics missing · Slow admin portal only	Next business day	Any engineer	Product backlog

P1 White-Label Violation Response — Exact Steps

!

If white_label_violations > 0 at any time post-launch

Execute within 15 minutes of detection — no exceptions

1 — Immediately roll back ECS to last known good task definition

$ aws ecs update-service \ --cluster GoVisaX-Prod-Cluster \ --service GoVisaX-Prod-Service \ --task-definition govisax-prod:LAST_GOOD_REVISION \ --region ap-south-1

2 — Identify which endpoint exposed the reference

$ aws logs filter-log-events \ --log-group-name /ecs/govisax-prod \ --filter-pattern "visa2fly" \ --start-time $(date -d '1 hour ago' +%s000) \ --region ap-south-1

3 — Notify Legal/BD if customer-facing exposure confirmed

# Send incident report to: legal@govisax.com, cto@govisax.com # Include: timestamp, endpoint, number of affected responses, customer IDs if known # Assess V2F contract implications — exposure may trigger notice obligation

Appendix B

Launch Day Hour-by-Hour Timeline

Recommended sequencing for the day of go-live. All pre-flight items (Steps 1–2) must be complete before T-0. Schedule launch for a Tuesday–Thursday morning (avoid Mondays and Fridays for operational risk reasons).

T-72h

3 Days Before

Confirm V2F Credentials Received

Final check that Visa2Fly B2B production API key + secret are in AWS Secrets Manager. If not received, do not proceed — notify BD Lead to escalate with V2F account manager.

T-24h

Day Before

All Pre-Flight Items Signed Off

Walk through every item in the Pre-Flight Checklist. Confirm ACM certs, Route53 hosted zone, GitHub secrets, SES production access, PagerDuty rotation, and beta user list are all ready. DevOps on-call rotation begins.

T-0

Launch Day 08:00 IST

CDK Deploy Begins (Step 3)

Run cdk deploy GoVisaX-Prod. Monitor in terminal. Run MySQL schema migration immediately after CDK completion. ETA: 08:25 IST.

T+30m

08:30 IST

DNS Cutover (Step 4)

Update Route 53 records. Verify all 7 domains resolve correctly within 5 minutes. Confirm HTTPS works on all endpoints.

T+45m

08:45 IST

CI/CD Pipeline + WL Scan Gate (Steps 5–6)

Push tag to main. Watch GitHub Actions. All 7 stages must pass green. White-label scan gate (Stage 3) is the critical gate. ETA: 08:53 IST.

T+60m

09:00 IST

k6 Load Test Smoke Scenario (Step 7)

Run smoke scenario (1 VU × 30s). If all thresholds pass including white_label_violations == 0, proceed. Run full suite in background.

T+90m

09:30 IST

Monitoring Activated + Soft Launch (Steps 8–9)

Confirm all CloudWatch alarms are in OK state. Admit 100 beta users. Run E2E test transaction (real Dubai Tourist visa application). Begin 48-hour monitoring window.

T+48h

+48 Hours — Go/No-Go

Public Launch Decision Meeting

Review: zero P1 incidents ✓ · WL violations == 0 ✓ · p95 < 800ms ✓ · Error rate < 0.5% ✓ → Approve public launch (Step 10). If any condition fails, hold and remediate.

🚀

T+50h — Public Launch

GoVisaX Opens to the World

Remove beta allow-list · Switch Razorpay to live mode · Enable auto-scaling · Publish press release · Notify partner API waitlist · Submit mobile apps to app stores.

ProductionGo-LiveRunbook

Pre-Flight Gates — Complete Before Touching Infrastructure

Sign Visa2Fly B2B API Agreement

Registration Checklist

Populate AWS Secrets Manager

Deploy AWS Infrastructure via CDK

DNS Cutover — Route 53

Trigger CI/CD Pipeline — Build & Deploy Application

7-Stage Pipeline Execution — What to Watch

White-Label Scan Gate — Verify Zero V2F Exposure

8 White-Label Controls — Final Status

k6 Load Testing — Validate Performance at Scale

Pass/Fail Thresholds

Activate Monitoring & CloudWatch Alarms

Critical CloudWatch Alarms to Monitor During Launch

Soft Launch — 100 Beta Users, 48-Hour Monitoring Window

Soft Launch Checklist

Full Public Launch

Post-Launch First 24 Hours — Key Metrics to Watch

Incident Response — Severity Levels & Response Procedures

P1 White-Label Violation Response — Exact Steps

Launch Day Hour-by-Hour Timeline

Production
Go-Live
Runbook