DevOps & Cloud Deployment (Docker, Vercel, Render)

Deploy a reproducible release, then verify it

A deployment connects a built application, its runtime, environment settings and data services. A static frontend, a long-running API and a database may require different hosting capabilities. Choose a service because it matches the workload, not because its dashboard is familiar.

Prepare the application

1. Commit a lockfile and a repeatable build command.
2. Read the listening port from the host's environment and bind to the required interface.
3. Provide a lightweight health endpoint without private configuration values.
4. Keep uploads and database data outside disposable application containers.
5. Document environment variables without copying real secrets into the repository.

Container recipe for a small Node API

# Supply a supported, reviewed image tag at build time.
ARG NODE_IMAGE
FROM ${NODE_IMAGE}
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY --chown=node:node server/ ./server/
USER node
ENV NODE_ENV=production
CMD ["node", "server/index.js"]

This example assumes the chosen official Node image provides the node user and the application needs no compile step. Adapt it to the actual repository. A multi-stage build is appropriate when compiling frontend or TypeScript assets. Pin a reviewed tag or digest according to the team's update process.

Do not include secrets in the build context

# .dockerignore
node_modules
.git
.env
.env.*
*.log

Inject production credentials using the hosting service's secret configuration. A build argument or frontend variable is not a safe secret store. Restrict the database's network access and credentials to the application roles that require them.

Hosted frontend and API

A frontend platform such as Vercel may suit static builds and supported server functions. A service such as Render may host an application process and related services. Verify each provider's current runtime, persistence, limits and deployment instructions before selecting a plan. Configure the actual production API origin and allowed browser origins; localhost settings are not production settings.

Release and rollback checklist

Back up data before a migration, use backward-compatible changes where possible, deploy and check health, then exercise a real read/write path with a test account. Inspect safe logs and monitor error rates. Rollback of application code does not automatically reverse an incompatible database migration.

Practice

Containerize a development catalogue API, run it with a supplied port and database URL, then restart it to confirm data persistence is external. Write down how to restore the previous release. Reference: Dockerfile documentation.