How to Deploy Your First React App to Kubernetes
For React developers deploying their first app · Based on Cloud Guru React-to-Kubernetes Deploy Pattern
// TL;DR
If you're a React developer deploying to Kubernetes for the first time, the React-to-Kubernetes Deploy Pattern gives you a validated three-stage pipeline — Run Locally → Containerise with Docker → Deploy on Kubernetes — so you catch failures early instead of debugging a live cluster. You'll insert your API key into the Redux Actions layer, confirm the app works locally, build and test a Docker image, then rebuild it in your cloud Container Registry and expose it via NodePort. Start with NodePort (not LoadBalancer) to keep your first deployment simple and get a working public URL fast.
Why is deploying React to Kubernetes so error-prone the first time?
Most first-time deployments fail silently — the app builds, the deployment shows healthy, but the browser shows no data. This happens because generic tutorials skip validation and gloss over two contracts that matter most: the Port Consistency Contract and Container Registry Parity. The React-to-Kubernetes Deploy Pattern removes the guesswork by making you validate at every stage before moving on.
The core idea is the Three-Stage Pipeline: Run Locally → Containerise with Docker → Deploy on Kubernetes. You never jump straight to Kubernetes. Each stage proves the app works before you add the next layer of complexity, so when something breaks you know exactly which layer to look at.
How do I set up before writing any commands?
Get all prerequisites first. Secure your external API key (like an OMDB-style movie API key), install Node.js, start Docker Desktop, and export your registry identity once:
```
export DOCKER_USERNAME=
```
This environment variable must persist for the whole session — you'll reference `$DOCKER_USERNAME` in every build and tag command so your image names stay consistent. You also need a pre-created namespace in your target cluster and your cluster name on hand for the final expose step.
Where does my API key go?
Into the Redux Actions layer — not a Component, not a Container. This follows the Components vs. Containers architecture: Containers hold logic and state, Components are purely presentational, and all API calls live in Actions. Paste your key into the API call inside the Actions file. Confirm the app defines start, success, and error action types so you can add loading skeletons later.
How do I validate locally before containerising?
Clone the repo, `cd` in, and run `npm install`. Then compile your styles and start the app:
```
npm run build:css
npm run start
```
Skipping `build:css` is a classic first-timer mistake — your Sass won't compile and styles will be missing. Open localhost, confirm the API returns data, and only then proceed.
Next, containerise:
```
docker build -t $DOCKER_USERNAME/
docker images
docker run -p
```
Visit `localhost:
How do I deploy to the cluster?
Because managed providers require Container Registry Parity, rebuild the image inside your provider's registry. For IBM Cloud:
```
ibmcloud cr build -t registry.
```
Then create and expose the deployment:
```
kubectl create deployment
kubectl expose deployment
```
Use NodePort, not LoadBalancer — it's sufficient for a first deployment. The `--port` value must match the Dockerfile EXPOSE port. This single contract causes the most silent failures for beginners.
Finally, get your public URL:
```
ibmcloud cs workers
kubectl describe service
```
Your app is live at `
What's my next step?
Start with a small React app that calls a single API, follow the pipeline end to end, and confirm each stage before moving on. Once you have a working NodePort deployment, you can explore migrating to LoadBalancer for production traffic. Clone an IBM Code Pattern repo and run through all ten workflow steps to get your first live cluster deployment today.
// FREQUENTLY ASKED QUESTIONS
Do I really need to test in Docker before deploying to Kubernetes?
Yes. The Three-Stage Pipeline requires you to run and validate the Docker image locally before deploying. If the containerised app doesn't work on your machine, it won't work on the cluster. Testing locally isolates containerisation issues from Kubernetes issues, so you always know which layer failed.
What port should I use for my first deployment?
Use whatever port your Dockerfile declares in its EXPOSE instruction, and use that exact same number in the kubectl expose --port flag. The specific number matters less than consistency — the Port Consistency Contract is the top cause of silent failures for first-timers.
Should I start with NodePort or LoadBalancer?
Start with NodePort. It opens a port on every worker node and is sufficient to expose your service externally for a first deployment. LoadBalancer adds complexity and cost for advanced traffic management you don't need yet — you can migrate to it later without rebuilding your image.