Elastic Beanstalk
PHP
Node.js
platform migration
AWS

Change platform on Elastic Beanstalk from PHP to Node.js

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Moving an Elastic Beanstalk application from PHP to Node.js is not just a source-code change. It is a platform migration. In practice, the safest path is usually to create a new Node.js environment, deploy the Node.js app there, verify behavior, and then cut traffic over, rather than trying to force an in-place platform switch on a live PHP environment.

Why a New Environment Is Usually Better

Elastic Beanstalk environments are tied to a platform branch that defines the runtime, deployment hooks, proxy behavior, and health model. Switching from PHP to Node.js changes all of those assumptions at once.

That is why a blue-green style migration is usually safer:

  1. build the Node.js application
  2. create a new Elastic Beanstalk environment using the Node.js platform
  3. migrate configuration and environment variables
  4. test the new environment
  5. swap CNAMEs or move traffic over

This keeps the old PHP environment available as a rollback target.

Create the Node.js App Bundle

A minimal Node.js Elastic Beanstalk app usually needs:

  • 'package.json'
  • an application entry point
  • a process that listens on the port provided by the environment

For example:

json
1{
2  "name": "example-app",
3  "version": "1.0.0",
4  "main": "server.js",
5  "scripts": {
6    "start": "node server.js"
7  },
8  "dependencies": {
9    "express": "^4.19.2"
10  }
11}

And the server:

javascript
1const express = require("express");
2
3const app = express();
4const port = process.env.PORT || 8080;
5
6app.get("/", (_req, res) => {
7  res.send("Node.js app running on Elastic Beanstalk");
8});
9
10app.listen(port, () => {
11  console.log(`listening on ${port}`);
12});

Binding to process.env.PORT is important because Elastic Beanstalk’s platform expects the app to listen on the environment-provided port.

Create a New Elastic Beanstalk Environment

From the AWS CLI, a simplified flow looks like this:

bash
eb init
eb create my-node-env --platform "Node.js"
eb deploy

If you use the console instead, the same idea applies: choose the Node.js platform when creating the new environment instead of reusing the PHP platform assumptions.

After deployment, confirm:

  • health checks pass
  • environment variables are present
  • database or queue connections work
  • static assets and reverse proxy behavior are correct

Migrate Configuration, Not Just Code

The app code is only part of the move. Environment settings often differ between PHP and Node.js deployments:

  • startup command
  • environment variables
  • proxy or static-file mappings
  • health check path
  • log expectations

For example, a Node.js app may use npm start or a Procfile, while the PHP environment relied on Apache or PHP-FPM defaults. Those assumptions do not carry over automatically.

Cut Over with a CNAME Swap

Once the Node.js environment is healthy, the usual Elastic Beanstalk cutover pattern is a CNAME swap. That lets traffic move to the new environment without immediately destroying the old one.

Operationally, this is much cleaner than a risky in-place platform mutation because:

  • rollback is simpler
  • old logs remain available
  • you can verify health before cutover
  • DNS-facing entry points stay stable

That is the main reason the new-environment approach is preferred.

Common Pitfalls

The most common mistake is treating this as only a language rewrite. On Elastic Beanstalk, PHP and Node.js platforms have different runtime and deployment expectations, so the environment itself is part of the migration.

Another pitfall is trying to reuse the old PHP environment in place without a rollback plan. Even if a platform update path appears possible, it is a much riskier cutover than creating a parallel Node.js environment.

It is also easy to forget process.env.PORT. A Node.js app that listens on a hardcoded local port may work on a laptop and fail under Beanstalk health checks.

Finally, do not migrate only code and forget environment variables, health-check paths, and platform-specific config. A successful platform move is an operational migration as much as an application migration.

Summary

  • Treat PHP to Node.js on Elastic Beanstalk as a platform migration, not only a code rewrite.
  • The safest path is usually a new Node.js environment plus traffic cutover.
  • Make the Node.js app listen on the environment-provided port.
  • Migrate environment settings and health-check assumptions explicitly.
  • Use blue-green style rollout or CNAME swap so rollback stays easy.

Course illustration
Course illustration

All Rights Reserved.