Enrique Dela Peña Jr.

Enrique Dela Peña Jr.

Platform & DevOps Engineer

I build and automate the systems that keep software running.

Platform & DevOps Engineer with experience in network operations, software QA and AI-assisted development.

Play the demo Let's talk See the engineering work Download CV (PDF)
Focus
Platform & DevOps
Open to
Full-time or contract · Remote preferred

Key Metrics

11/33levels

Demo levels completed

11 finished, 22 did not — 33 tracked attempts since launch.

12–15min

Infra apply time

Terraform provisions the EKS + Redis + load balancer stack from scratch; teardown runs in 8–10 min.

4–6min

Full-stack deploy time

One CI pipeline deploys game and web together; Android ships separately in 3–5 min.

222tests

Automated tests

54 server-side (Node) + 168 Godot client tests, run in CI before deploy.

9engineers

NOC team led

Lead Technical for Network operations team, Globe Telecom — before moving into software.

02 Engineering Capabilities

Cloud Infrastructure

I build the cloud infrastructure applications run on, with security and cost controls built in.

DevOps & Delivery

I turn code changes into tested deployments instead of relying on manual release steps.

Quality & Reliability

I test software and infrastructure before changes reach users.

AI-Assisted Engineering

I use AI agents to do implementation work faster while I keep control of the design, review and final decision.

Engineering Process

The game is only one part of the system. I built the infrastructure, delivery pipeline and verification process around it.

From idea to release
  1. RequirementsDecide what needs to exist
  2. CloudBuild the infrastructure
  3. DevOpsAutomate delivery
  4. ApplicationRun the application
  5. QAVerify the result
  6. ReleaseRelease when it meets the expected result

AI agents — accelerate implementation

Open a card for the diagram and implementation evidence.

Showing all 4 skills

Cloud

Build it so it can be rebuilt.

OpenClose

I define the infrastructure so it can be recreated, secured and controlled for cost.

Tools & techTerraformAWS (EKS, EC2, ElastiCache)KubernetesDockerGitHub ActionsCloudflare TunnelClaude Code

From requirements to running infrastructure Seven steps turn requirements into running infrastructure: define the requirements, set access rules, separate environments, choose resources, add security and cost guardrails, define the environment as Terraform code, then provision, deploy and verify the result before release. 1 · Define requirements needs, access and cost limits 2 · Set access rules who can access each resource 3 · Separate environments development and production apart 4 · Choose resources services and capacity to fit needs 5 · Add guardrails security and cost boundaries steps 1–5 are written decisions — nothing is built yet 6 · Plan the build decisions become an implementation plan reviewed before provisioning starts before infrastructure is built approval is its own step 7 · Define and build as code Terraform defines the environment recreate it consistently then provision and verify ready for DevOps CI/CD & application deployment requirements guide the infrastructure, not the other way around
From requirements to running infrastructure · Click any step to read what it means.
Show 2 recorded runsHide recorded runs
Terraform apply standing the EKS environment up from nothing — 12 to 15 minutes end to end.
The same environment destroyed again in about the same time — what deploy-on-demand costs when nobody is playing.
Show 7 stepsHide steps

Business DeliverablesTechnical RequirementsAI-Assisted Discovery

Set player capacity, latency and monthly cost limits before choosing the architecture. For a game still in development, this ruled out keeping a full cluster running all the time.

CredentialsIAM & OIDCSecrets Management

Define who or what can access each resource. CI uses short-lived credentials through OIDC, not long-lived ones; IAM roles scope what each identity can access.

Environment StrategyNetwork ArchitectureResource Isolation

Keep development and production isolated so testing changes cannot accidentally affect the live environment. Production, staging and development have separate networking; the EKS path is deploy-on-demand, while staging and development use an already-paid-for Linux machine through Cloudflare Tunnel.

Resource ManagementCapacity & ScalingBudget Forecasting

Select the AWS services and capacity based on the requirements instead of starting with infrastructure and fitting the application around it. Instance families, cache tier and availability zones are checked against the cost ceiling; this kept encrypted ElastiCache and ruled out a separate load-balancer controller.

Security BaselinesCompliance ConstraintsCost Control

Set boundaries around access, resources and spending before deployment. The infrastructure should be difficult to misuse and easy to control. Encryption, tagging, monitoring, backup, quotas and budgets apply at provisioning time.

Consolidated BriefImplementation PlanFinal Review

Combine the requirements and infrastructure decisions into an implementation plan before provisioning resources. I review the plan before the build starts; Terraform and the manifests carry that plan into implementation.

Infrastructure as CodeDeployment TestingRepeatability

Terraform defines the infrastructure so the environment can be recreated consistently instead of configured manually. Provision the environment, deploy the required services and verify the result; installation stops if the prior infrastructure apply did not complete, and the EKS environment takes 12–15 minutes to create or remove.

DevOps

Ship it the same way every time.

OpenClose

I automate delivery so changes follow the same tests, security checks and deployment controls.

Tools & techGitHub ActionsComposite ActionsDockerGodot Export (GUT)Google Play Publisher APICloudflare R2Claude Code

From code change to controlled release One pipeline fanning out to five destinations, fed by the Cloud and AI cards. Step one, on the left: planning names the five destinations before anything is written — the game server and the web client each in production and in development, and the Android build in a limited Play Console internal testing track — and decides in the same breath how much trust each one gets. Step two is the trunk in the middle: a single body of shared pipeline code that every destination calls, so a fix lands once, with each destination still running its own steps where it actually differs, such as signing the Android build with a key unlocked only for that step, or hash-checking art before it is allowed into the build, either one failing the build outright. Step three is the five destinations on the right, reached by five branches leaving that one trunk. A dashed vertical clearance gate sits between them: the two production branches and the Android branch cross it, while the two development branches pass below where it ends, because development is the only destination allowed to start a deploy from a push, and each environment carries its own credentials so a leaked development key cannot reach production. Step four, at the bottom left and drawn greyed out, is monitoring: reading what is actually running in each environment and alerting on drift. It is on the roadmap, not built yet. environments and guardrails from Cloud the brief and the review loop from AI 1 · Choose the destination five destinations, one pipeline 2 · Run the checks shared actions, tests and validation 3 · Authenticate securely OIDC access expires with the job development passes below 4 · Verify what gets deployed Game server · production Web client · production Android · internal track Game server · development Web client · development would read from the live destinations Monitoring — Planned planned — not built yet 5 · Control the release 6 · Deploy and clean up — gates clear before release; temporary infrastructure is removed when no longer needed
From code change to controlled release · Click any step to read what it means.
Show 3 recorded runsHide recorded runs
One pipeline run deploying every destination.
The teardown workflow returning every destination to zero.
The Android client build, signed and pushed to the internal testing track.
Show 7 stepsHide steps

Destination MatrixTrust AllocationGate Policy

One pipeline supports the project's different destinations instead of maintaining separate release processes. It serves five destinations: production and development for the game server and web client, plus Android's internal testing track.

Brief-Driven ImplementationShared Composite ActionsFail-Closed Checks

Every change passes the required tests and validation before deployment continues. Shared GitHub Actions composite actions keep the checks consistent across destinations.

Staged RolloutEnvironment IsolationCredential Scoping

CI authenticates with short-lived credentials through OIDC, not long-lived ones. Each environment has separate credentials, and Android signing unlocks its key for one step.

Artifact verificationFail-closed checksBuild integrity

Deployment uses the expected build artifact and verifies it before releasing it to the target environment. Every build hash-checks its art; a failed check stops the build.

Deployment gatesEnvironment isolationProtected environments

Protected environments require the appropriate approval or deployment gate before a release can continue. Only development deploys from a push; every other release has to clear that gate, with environment isolation keeping credentials separate.

DeploymentTeardownTemporary infrastructure

Deploy to the selected environment and remove temporary infrastructure when it is no longer needed. Teardown returns temporary destinations to zero.

Live-State VerificationAlerting & EscalationFuture Work

Planned, not yet built: read the live state in each destination and alert on drift from the deployed result.

Full auto-deploy, once it has been earned

Development already deploys itself on a push. Extending that to production is built, ready, tested but deliberately switched off.

QA

Whoever builds it is the worst person to judge it.

OpenClose

I separate building from acceptance, so the agent never grades its own work.

Specification → Build → Automated tests → Manual verification → Fix → Documentation

Tools & techGitHub ActionsNode.js test runnerGUT (Godot tests)Claude CodeMarkdowns

How work gets checked before it counts as finished A six-step cycle. One: the feature specification and the expected results are written before any planning or building starts. Two: the coding agent plans, builds, and applies the fixes that come back to it. Three: scripted automated tests run before a human looks at anything. Four: I test the output by hand and compare it against the expected results. Five: anything that does not match is written up as a specific, scoped fix instruction, with the session context kept concise so the agent cannot hallucinate, and the cycle returns to step two. Six: once every expected result is met, the documentation is updated and then compacted to a context budget — and that compacted documentation is what the next task, and the agent working it, reads as its context. 5 · Fix instruction what to fix · context kept concise 1 · Spec first what it must do, and the results I expect to see 2 · Agent builds planning, building and fixing what comes back 3 · Automated tests scripted checks run before I look at anything 4 · Manual testing actual output against the expected results all results met 6 · Docs updated then compacted — 13 docs, 1–2 read per task read as context at the start of the next task One bug passed every automated test a missing drag preview, caught only by rendering the play field to an image. That is what step 4 is for.
Click any step to read what it means.
Show 6 stepsHide steps

Acceptance CriteriaTest PlanningShift-Left Testing

Before planning or building, I write what the feature must do and the exact expected result. Everything after that is measured against the list.

How that specification gets built in the first place

Separation of DutiesTest IndependenceImplementation Hand-off

The coding agent plans, implements and fixes from the specification. It has no say in whether the result passes — that's judged against step one's expected results.

Test AutomationContinuous IntegrationRegression Suites

The server suite, Godot suite and CI build run first. They handle repeatable checks consistently; any failure returns the work before manual review.

Exploratory TestingManual VerificationCoverage Gaps

Passing tests cover only what was anticipated. I run the real result against step one's expectations, not whether it merely looks finished or the agent sounds confident.

Defect ReportingActual vs ExpectedContext Control

A mismatch returns as a written instruction: what is wrong, where, and what was expected. I keep the context small so the fix remains scoped to the problem rather than reopening the feature.

Documentation MaintenanceTraceabilityContext Budget

Documentation records what shipped, then is compacted to stay within the context budget. Notes that grow without limit stop being useful to both reviewer and agent.

AI-assisted engineering

Let AI do the work. Keep the decisions.

OpenClose

I use AI agents for implementation while I control the requirements, context, architecture and acceptance.

Define → Refine → Retrieve → Plan → Implement → Hand off to QAAI handles more of the typing. I remain responsible for the engineering.

Tools & techClaude CodeCodexCursorChatGPTMCP tool serversGit

From request to implementation handoff Six steps turn a request into verified implementation: define the task, refine the context, retrieve only what matters, plan the change, implement it, then test and review it with human acceptance. 1 · Define the task goals, expected results, constraints before asking the agent to act 2 · Refine the context focused instructions, less noise right model and effort 3 · Retrieve what matters retrieve, don't load all documents and files on demand 4 · Plan the change review plans before work human owns the decision 5 · Implement work follows the approved plan with focused context 6 · Hand off to QA separate testing and acceptance the next process owns verification hands off to the QA cycle from here AI accelerates implementation; engineering decisions stay human-owned
From request to implementation handoff · Click any step to read what it means.
Show 6 stepsHide steps

Prompt engineeringContext controlToken efficiency

I start with research and a scoped task, not code. Larger requests are split into smaller phases, with constraints and edge cases defined before the agent starts planning.

Model selectionEffort routingPrompt compression

I give the agent focused instructions instead of unnecessary information. This reduces noise and keeps the task aligned with the intended result.

RAGContext routingSelective loading

The coding agent does not need the entire repository. Relevant documents and files are identified and loaded when the task needs them.

PlanningHuman approvalReview

The agent proposes an implementation plan before changing the code. I review the approach and remain responsible for the engineering decision.

Agent executionImplementationCode changes

The agent handles the implementation work using the approved context and plan.

Human-in-the-LoopPlan ApprovalContext Maintenance

Once implementation is complete, it moves into the separate QA process for automated testing, manual verification and acceptance.

Local LLMs, once the hardware exists

The current workflow uses cloud models. If capable local hardware becomes available, the retrieval router is the first part to move; the source documents and approval process stay the same.

03 Other Projects

Projects where I built, shipped or operated the systems behind the software.

In production

SpaceSheeps Pinball

Arcade · Android · Leaderboard

Released Android game. Built from prototype to Google Play, including Google Play services and the release pipeline.

itch.io Google Play YouTube

  • Built in Godot 4.
  • Production released on Google Play Store in June 2025.
  • Integrated with Google Play APIs for Sign-In, leaderboard, and in-app donations plugins with Java/Kotlin.

In development

04 Career

I started by keeping networks running, moved into software QA, and now build the platform between software and production.

Network operations

5 years keeping enterprise systems available, handling incidents, escalations and failover.

Software QA

I learned to test software from the other side of the system — finding problems before they reach users.

Platform & DevOps

I now bring those two perspectives together when designing infrastructure, deployment and engineering workflows.

CV

Every role below, most recent first.

Download CV (PDF) Updated August 2026

Professional work history

7 roles

QA Tester Sep 2025 — Present

Amber · Philippines, on-site Test game builds end to end and support release quality through structured QA and CI/CD tooling.
  • Execute and document game testing end to end — bug identification, tracking, and regression verification — to safeguard release quality.
  • Design structured test plans and test cases across functional and developmental QA, feeding into QA strategy and cost estimation.
  • Work daily inside Jenkins pipelines, Git/GitHub, ZTNA and authenticator-gated access, and build distribution systems as part of the release workflow.
  • Collaborate with developers, producers and cross-functional stakeholders on release-ready builds.
  • Propose tools, workflows and QA practices that reduce repeat effort.

Indie Game Developer Jan 2025 — Present

Galaxxi Games (freelance) · Remote Build games and the cloud infrastructure, delivery pipeline and release process behind them.
  • Built the full platform for Top or Drop: Terraform-managed AWS infrastructure, an authoritative Node.js WebSocket server on Redis shared state, and a Godot client — publicly playable, source public.
  • Designed one GitHub Actions pipeline deploying to five destinations through shared composite actions; only development self-deploys on push, every other target clears a gate first.
  • Established CI authentication with short-lived credentials through OIDC, not long-lived ones, plus per-environment credential isolation and encryption, tagging, quota and budget guardrails.
  • Ran production, staging and development as separate targets with their own networking — the EKS path written and tested, held deploy-on-demand until release, while staging and development share one already-paid-for Linux machine reached through a Cloudflare Tunnel.
  • Defined the entire platform as code so it can be destroyed and rebuilt from one source, with the deploy itself as the test — it halts before installing anything if the previous apply never completed.
  • Shipped SpaceSheeps Pinball, live on Google Play since June 2025 — Godot 4 from prototype to release, with Play Sign-In, leaderboard and in-app donation APIs in Java/Kotlin.

Career break May 2021 — Dec 2024

Independent · Philippines Full-time family caregiving break.
  • Full-time family caregiving alongside a residential construction project and continued technical study.

Network Engineer Specialist — Client Service Assurance Dec 2019 — Apr 2021

Verizon Business · Philippines, hybrid Kept a multinational retailer's U.S. network up — monitoring, fault isolation and failover across VoIP, IPVPN, WAN and DIA.
  • Monitored and maintained VoIP, IPVPN, WAN, LAN, WLAN and DIA circuits for a multinational retail enterprise's U.S. operations.
  • Handled alarm detection, automated ticketing, fault isolation and failover verification to keep services up through incidents.
  • Resolved escalations on bridge calls with engineers, users and internal teams, investigating recurring faults with RFC, BERT, OTDR and CLI/SSH tooling.
  • Worked across Cisco and HP Aruba enterprise network equipment throughout, on the customer estate and on the escalation path behind it.
  • Received Customer Excellence and Supervisor's Choice awards for support during the COVID-19 pandemic.

Lead Technical Network Operations Engineer Jun 2017 — Dec 2019

Globe Telecom · NCR, Philippines, on-site Led a nine-engineer NOC team owning first-level escalations for enterprise circuits.
  • Led a nine-engineer NOC team, coordinating operations and first-level escalations.
  • Owned first-level escalations for enterprise circuits, driving fault resolution and service continuity.
  • Evaluated newly provisioned circuits for resiliency, design compliance and service reliability.
  • Coordinated outages, migrations and maintenance windows with Field Operations.

Network Operations Engineer Jun 2016 — Jun 2017

Asticom Technology Inc. (deployed to Globe Telecom / DRI) · Mandaluyong, Philippines, on-site Fault monitoring, escalation and ticket resolution across METRO-E, DIA and IPVPN enterprise circuits.
  • Handled fault monitoring, escalation and ticket resolution for METRO-E, DIA and IPVPN enterprise circuits.
  • Maintained daily logs and ticket backlogs, and traced recurring outages back to their cause.
  • Recommended circuit resiliency improvements based on what the backlog kept showing.

Network Operations Engineer Jul 2015 — Jun 2016

ECI (deployed to Smart Communications Inc.) · Makati, Philippines, on-site First role — 3G/LTE service provisioning and first-level fault isolation in transmission networks.
  • Provisioned, tested and activated 3G/LTE services across SDH and Data Link layers in transmission networks.
  • Monitored alarms via NMS, performed first-level fault isolation, and covered on-call support for live testing and troubleshooting.
  • Served as Tier 1 Shift Lead from January to June 2016, handling shift turnover and task coordination.

Education & certifications

3 entries

  • BS Electronics and Communications Engineering Degree 2008 — 2014

    University of the East

  • Licensed Electronics Engineer Licence Oct 2014

    Professional Regulation Commission (PRC), Philippines

  • Nokia-Huawei SD-WAN Training Apr 2018

    Globe Telecom 32 hours, covering virtual WAN operations.

05 Technologies

Cloud & infrastructure Open Close
AWS (EKS, EC2, ElastiCache, S3, IAM)TerraformKubernetesDockerCloudflare (Tunnel, R2, Workers)Linux
CI/CD & automation Open Close
GitHub ActionsComposite actionsJenkinsOIDC federated CI identityGated multi-environment deploysArtifact hash verificationGoogle Play Publisher APIGit / GitHub
Languages & runtimes Open Close
Node.jsPythonBashGDScriptJava / KotlinC#RedisWebSocket (ws)
Client & game Open Close
Godot 4Android builds & signingGoogle Play Console
Security & access Open Close
IAM policy scopingShort-lived credentialsSecrets managementZero Trust access (Okta, Twingate)
QA & testing Open Close
Test plan & test case designFunctional & regression testingExploratory testingGUT (Godot)Node.js test runnerJiraTestRailConfluence
Networking & operations Open Close
NOC operationsIncident & escalation managementCiscoHP ArubaSD-WAN (Nokia–Huawei)VoIPIPVPNMETRO-EDIAWAN / LAN / WLANSDH transmission3G / LTE provisioningNMS alarm monitoringFault isolation & failoverHigh-availability designBERT / OTDRCLI / SSH
AI-assisted engineering Open Close
Claude CodeCodexCursorMCP tool serversPrompt & context engineeringRetrieval-augmented generation

06 Let's talk

Platform & DevOps Engineer

Open to Platform & DevOps roles.

Let's talk Email hire@galaxxigames.com GitHub LinkedIn CV

Let's talk

Have a role, project, or opportunity in mind? Tell me a little about it and I'll get back to you.

Prefer your own mail client? hire@galaxxigames.com