Just wondering, when was the last successful build step?

[mxchinegod]

All of them are failing or turned off so I'm just wondering what to install/pull? There are many, many "closed" issues with the Dockerfile, 'sharp', build step yet none of the suggestions from the team have solved the issues.

Many issues are closed before build step is considered.

Is this stable enough to use in production or no?

Again, getting the basic 2.x, 3.0 create-app Dockerfiles to work is incomplete, so it would be good to focus not on getting a dev environment running (since that only takes you so far!) but can anyone confirm this builds without issues with 'sharp', OOTB, without modifications?

I can link to all of the issues I have mentioned but I have a suspicion a lot of it is fresh in memory for the team :) there are a LOT of complaints about 'sharp', dockerfile from vanilla app not working, but they are closed early.

[jmikrut]

Hey @mxchinegod are you referring to the Payload core codebase?

In that case we have a LOT of tests and a few specific tests are flaky, so the build can show as errored even if there is a flake in a test. We are working toward ensuring that the flakes are ironed out but it can be difficult especially on the E2E side. We tend to prioritize fixes over flakes and then circle back to ensuring tests are as flake-less as possible.

Many issues are closed before build step is considered.

Issues do not necessarily correlate to build steps, so I am not following there, but we try our hardest to keep up with issues that are reliably reproducible and can be demonstrated to be a bug. In practice, many issues are created which do not have a reproduction, are not reproducible even if we wrote our own, or are not related to Payload code. In those cases we do convert to Discussions in order to keep Payload's GitHub issues related to concrete bugs / issues with Payload core code.

Is this stable enough to use in production or no?

2.0 is, but 3.0 is definitely still in beta. There are lots of people that use it in production and we are close to having full stable, but that's kind of a "choose your own adventure" type deal at this point. If you're looking for as much stability as possible I'd stay on 2.0 until we hit 3.0 stable.

It sounds like you are mostly running into Docker / Sharp issues, which is fair, because Sharp is very, very picky. Generally there is an answer (Sharp is incompatible with certain Docker images, etc) and there are many issues but generally what that means for Payload is that we have to go diagnose someone's exact Docker / Sharp / Node / package manager versions and the answer can change depending on the exact combination of those factors. It's exhausting, frankly, and there might not be a single Dockerfile that works for everyone's exact use case. The Dockerfiles that we ship with might work for one machine, but might not for another.

This is more appropriate as a GitHub discussion though, and not an issue, for some of the reasons that I stated above (it's not a reproducible issue with Payload). Happy to keep the conversation going though and if you'd like to point us to an exact error that you're having, which we can reproduce, we would be happy to tackle it!

[r1tsuu]

Hi, I just want to say that I'm using 3.0 with Docker for like 5+ websites successfully. The only real issue is with Next.js standalone output - you cannot run migrations there, and the solution is simple - do not use it (at least while Payload hasn't solved somehow this), but then you end up with 1GB image size, which could be or couldn't be a big deal for you..

I had the sharp error too, but only when building on ARM64 arch (MacBook), on Linux (PC / Server) it's OK, which you should use on your server.

My Dockerfile for monorepo, where the Payload app has path apps/cms (without output: standalone:). If not using a monorepo + output: standalone enabled, Next.js example just works too https://github.com/vercel/next.js/blob/canary/examples/with-docker/Dockerfile
apps/cms/package.json -> "scripts.prod": "pnpm payload migrate && pnpm next start"

FROM node:20-alpine AS base
ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
RUN corepack enable

FROM base AS build
COPY . /usr/src/app
WORKDIR /usr/src/app
RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install --frozen-lockfile
RUN pnpm build:cms
RUN pnpm deploy --filter=@monorepo/cms /prod/cms

FROM base AS cms
COPY --from=build /prod/cms /prod/cms
WORKDIR /prod/cms
EXPOSE 3000
CMD [ "pnpm", "prod"]

If you even have issues with 2.0, I bet you're trying to build that on ARM64 - try a normal x86 PC.

[HarleySalas]

my standalone container size is 34mb, running migration during build. I'm not having any issues, not sure how so many seem to occur. I use a very slightly modified version of the Vercel provided standalone Dockerfile. I've got around 5 Payload 3 projects up and running on latest, or near latest versions as well.

Dockerfile:

FROM node:22-alpine AS base

FROM base AS deps

RUN apk add --no-cache libc6-compat
WORKDIR /app

COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* ./

RUN \
  if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
  elif [ -f package-lock.json ]; then npm ci; \
  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm i --frozen-lockfile; \
  else echo "Lockfile not found." && exit 1; \
  fi

FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

# Run migrations
RUN \
  if [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm migrate; \
  else echo "pnpm-lock.yaml not found, skipping migration."; \
  fi

RUN \
  if [ -f yarn.lock ]; then yarn run build; \
  elif [ -f package-lock.json ]; then npm run build; \
  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm run build; \
  else echo "Lockfile not found." && exit 1; \
  fi

FROM base AS runner
WORKDIR /app

# Install curl for health check
RUN apk add --no-cache curl

ENV NODE_ENV production

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public

RUN mkdir .next
RUN chown nextjs:nodejs .next

COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs

EXPOSE 3000

ENV PORT 3000

# Health check instruction
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
  CMD curl --fail http://localhost:3000/next/healthcheck || exit 1

CMD HOSTNAME="0.0.0.0" node server.js

[r1tsuu]

my standalone container size is 34mb, running migration during build. I'm not having any issues, not sure how so many seem to occur. I use a very slightly modified version of the Vercel provided standalone Dockerfile. I've got around 5 Payload 3 projects up and running on latest, or near latest versions as well.

Dockerfile:

FROM node:22-alpine AS base

FROM base AS deps

RUN apk add --no-cache libc6-compat
WORKDIR /app

COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* ./

RUN \
  if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
  elif [ -f package-lock.json ]; then npm ci; \
  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm i --frozen-lockfile; \
  else echo "Lockfile not found." && exit 1; \
  fi

FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

# Run migrations
RUN \
  if [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm migrate; \
  else echo "pnpm-lock.yaml not found, skipping migration."; \
  fi

RUN \
  if [ -f yarn.lock ]; then yarn run build; \
  elif [ -f package-lock.json ]; then npm run build; \
  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm run build; \
  else echo "Lockfile not found." && exit 1; \
  fi

FROM base AS runner
WORKDIR /app

# Install curl for health check
RUN apk add --no-cache curl

ENV NODE_ENV production

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public

RUN mkdir .next
RUN chown nextjs:nodejs .next

COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs

EXPOSE 3000

ENV PORT 3000

# Health check instruction
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
  CMD curl --fail http://localhost:3000/next/healthcheck || exit 1

CMD HOSTNAME="0.0.0.0" node server.js

This requires you to run a migration at the build time, which is useful when using SSG (and I'm using actually this on few sites), but not for a normal apps.
I also don't want to expose the database to public, here you need this if using Github Actions or something.