Frontend Project Deployment: Static Upload vs Containerized Deployment

This article, originally published on the Rare Earth Juejin Tech Community, shares practical experiences of deploying frontend projects using two approaches: pure static resource upload to a server and containerized deployment. It discusses their similarities, differences, and personal insights gained from hands‑on implementation.

Review of Previous Work

A year ago the author wrote a column about a frontend publishing platform built with Jenkins, Node, and React, which demonstrated a complete CI/CD pipeline for frontend projects. The overview diagram of that process is shown below.

The earlier CD flow used rsync to copy the built artifacts to a generic file server (e.g., Nginx or Apache) without any containerization.

The author raises the question: since frontend projects are just static files, why bother with containerization? The answer lies in the flexibility and control over the server environment that containers provide.

Differences Between Deployment Methods

Both methods ultimately deliver static assets to a web server, but they differ in who controls the server configuration.

Direct Server Upload

All frontend builds are uploaded via rsync to a file server managed by operations. Frontend developers have limited visibility into server settings such as CORS, gzip, or cache policies, which may require tickets to ops for changes. Log access can also be cumbersome.

In this model the server is a black box for frontend teams; any required configuration changes must be requested from the ops team.

Containerized Deployment

Using Docker and Kubernetes, each frontend project can be packaged into its own container with a custom Nginx configuration. This gives developers more control over headers, caching, and reverse‑proxy settings, but requires knowledge of Dockerfiles, image registries, and K8s resources.

The typical workflow includes building a Docker image that copies the dist folder into the Nginx image, pushing the image to a registry, and restarting the corresponding pod.

The following simplified Dockerfile illustrates the process:

FROM xxx.xxx.com/nginx:release

COPY ./dist/ /xxx/xxx/nginx/html/

CMD ["/bin/bash", "-c", "nginx -g 'daemon off;'"]

While containerized deployment adds steps—image build, registry push, pod restart—it empowers frontend teams to manage their own server configuration, set CORS headers, enable gzip, and adjust proxy rules.

Conclusion

Both deployment strategies ultimately serve the same static assets from a web server. Direct upload is simple but leaves server control to operations, whereas containerization provides greater flexibility at the cost of additional tooling knowledge. The choice depends on team structure, infrastructure maturity, and the need for fine‑grained server control.