Closed domosedov closed 1 year ago
We cannot recreate the issue with the provided information. Please add a reproduction in order for us to be able to investigate.
please add a complete reproduction
label?To be able to investigate, we need access to a reproduction to identify what triggered the issue. We prefer a link to a public GitHub repository (template for App Router, template for Pages Router), but you can also use these templates: CodeSandbox: App Router or CodeSandbox: Pages Router.
To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue. Ensure your reproduction does not depend on secrets, 3rd party registries, private dependencies, or any other data that cannot be made public. Avoid a reproduction including a whole monorepo (unless relevant to the issue). The easier it is to reproduce the issue, the quicker we can help.
Please test your reproduction against the latest version of Next.js (next@canary
) to make sure your issue has not already been fixed.
If you cannot create a clean reproduction, another way you can help the maintainers' job is to pinpoint the canary
version of next
that introduced the issue. Check out our releases, and try to find the first canary
release that introduced the issue. This will help us narrow down the scope of the issue, and possibly point to the PR/code change that introduced it. You can install a specific version of next
by running npm install next@<version>
.
Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.
Issues with the please add a complete reproduction
label that receives no meaningful activity (e.g. new comments with a reproduction link) are automatically closed and locked after 30 days.
If your issue has not been resolved in that time and it has been closed/locked, please open a new issue with the required reproduction.
Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the :+1: reaction on the topmost comment (please do not comment "I have the same issue" without reproduction steps). Then, we can sort issues by votes to prioritize.
We look into every Next.js issue and constantly monitor open issues for new comments.
However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.
Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.
I can't do a minimal reproduction as we are using ansible/docker. But if I downgrade the next version to 13.4.12, there is no problem.
Very likely related to: https://github.com/vercel/next.js/issues/53367
I have this same issue
I am using TurpoRepo and Goolge Cloud Run.
After Upgrading to 13.4.16 all my builds have failed since then.
// Ok next.js 13.4.12 logs
Listening on port 3000 url: http://5dc88ffe2408:3000
// Wrong next.js 13.4.13-13.4.17 logs
- ready started server on 172.18.0.5:3000, url: http://172.18.0.5:3000
help me please
Please read https://github.com/vercel/next.js/issues/54133#issuecomment-1681098185
"same" and similar comments are unhelpful and we cannot investigate. We need to see your application code to be able to debug further.
At the very least, paste in your Dockerfile
Please read #54133 (comment)
"same" and similar comments are unhelpful and we cannot investigate. We need to see your application code to be able to debug further.
At the very least, paste in your Dockerfile
// Dockerfile
FROM node:18-alpine AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY .npmrc 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 yarn global add pnpm && pnpm i; \
else echo "Lockfile not found." && exit 1; \
fi
FROM node:18-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
ENV NEXT_TELEMETRY_DISABLED 1
RUN npm run build
FROM node:18-alpine AS runner
WORKDIR /app
ENV NODE_ENV production
ENV NEXT_TELEMETRY_DISABLED 1
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
COPY --from=builder /app/next.config.js ./
COPY --from=builder /app/sentry.properties ./
COPY --from=builder /app/.sentryclirc ./
COPY --from=builder /app/public ./public
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
CMD ["node", "server.js"]
Pages Router
next.js 13.4.12
next.js 13.4.13-13.4.17
I tried setting "HOSTNAME" in "Dockerfile", if I set "localhost", I get a "50*" error, if I set "0.0.0.0", I get hard navigation when using "router.push()"
Open https://test-server.lectr.ru/lectures/17 wait...
Expected: https://test-server.lectr.ru/lectures/17-chto-takoe-naivnoe-iskusstvo
Result: http://172.18.0.5:3000/lectures/17-chto-takoe-naivnoe-iskusstvo
Dockerfile
FROM node:alpine AS base
FROM base AS builder
RUN apk add --no-cache libc6-compat
RUN apk update
WORKDIR /app
RUN yarn global add turbo
COPY . .
RUN turbo prune --scope=main --docker
FROM base AS installer
RUN apk add --no-cache libc6-compat
RUN apk update
WORKDIR /app
COPY .gitignore .gitignore
COPY --from=builder /app/out/json/ .
COPY --from=builder /app/out/yarn.lock ./yarn.lock
RUN yarn install
COPY --from=builder /app/out/full/ .
RUN yarn turbo run build --filter=main...
FROM base AS runner
WORKDIR /app
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
USER nextjs
COPY --from=installer /app/apps/main/next.config.js .
COPY --from=installer /app/apps/main/package.json .
COPY --from=installer --chown=nextjs:nodejs /app/apps/main/.next/standalone ./
COPY --from=installer --chown=nextjs:nodejs /app/apps/main/.next/static ./apps/main/.next/static
COPY --from=installer --chown=nextjs:nodejs /app/apps/main/public ./apps/main/public
CMD node apps/main/server.js
Logs
DEFAULT 2023-08-17T15:06:09.147493Z - ready started server on 127.0.0.1:8080, url: http://127.0.0.1:8080
DEFAULT 2023-08-17T15:06:10.014579Z - [36minfo[39m Loaded env from /app/apps/main/.env.production
DEFAULT 2023-08-17T15:06:10.452856Z - [36minfo[39m Loaded env from /app/apps/main/.env.production
DEFAULT 2023-08-17T15:08:41.319421Z - ready started server on 127.0.0.1:8080, url: http://127.0.0.1:8080
DEFAULT 2023-08-17T15:08:42.110014Z - [36minfo[39m Loaded env from /app/apps/main/.env.production
DEFAULT 2023-08-17T15:08:42.571185Z - [36minfo[39m Loaded env from /app/apps/main/.env.production
ERROR 2023-08-17T15:10:08.382230Z Default STARTUP TCP probe failed 1 time consecutively for container "frontend-main-monafiz-1" on port 8080. The instance was not started.
ERROR 2023-08-17T15:12:39.963337Z Default STARTUP TCP probe failed 1 time consecutively for container "frontend-main-monafiz-1" on port 8080. The instance was not started.
DEFAULT 2023-08-17T15:13:31.197730Z - ready started server on 127.0.0.1:8080, url: http://127.0.0.1:8080
DEFAULT 2023-08-17T15:13:31.923767Z - [36minfo[39m Loaded env from /app/apps/main/.env.production
DEFAULT 2023-08-17T15:13:32.367534Z - [36minfo[39m Loaded env from /app/apps/main/.env.production
DEFAULT 2023-08-17T15:16:03.022532Z - ready started server on 127.0.0.1:8080, url: http://127.0.0.1:8080
DEFAULT 2023-08-17T15:16:03.814854Z - [36minfo[39m Loaded env from /app/apps/main/.env.production
DEFAULT 2023-08-17T15:16:04.264939Z - [36minfo[39m Loaded env from /app/apps/main/.env.production
ERROR 2023-08-17T15:17:30.354029Z Default STARTUP TCP probe failed 1 time consecutively for container "frontend-main-monafiz-1" on port 8080. The instance was not started.
@balazsorban44 Here is a reproduction https://github.com/mjad218/next-js-cloud-run
just a simple app created with create-next-app
Build logs :
Step #2 - "Deploy": Deployment failed
Step #2 - "Deploy": ERROR: (gcloud.run.services.update) Revision 'next-js-cloud-run-00003-yiy' is not ready and cannot serve traffic. The user-provided container failed to start and listen on the port defined provided by the PORT=8080 environment variable. Logs for this revision might contain more information.
Step #2 - "Deploy":
Step #2 - "Deploy": Logs URL: https://console.cloud.google.com/logs/viewer?project=mobtakr-386219&resource=cloud_run_revision/service_name/next-js-cloud-run/revision_name/next-js-cloud-run-00003-yiy&advancedFilter=resource.type%3D%22cloud_run_revision%22%0Aresource.labels.service_name%3D%22next-js-cloud-run%22%0Aresource.labels.revision_name%3D%22next-js-cloud-run-00003-yiy%22
Step #2 - "Deploy": For more troubleshooting guidance, see https://cloud.google.com/run/docs/troubleshooting#container-failed-to-start
Finished Step #2 - "Deploy"
ERROR
ERROR: build step 2 "gcr.io/google.com/cloudsdktool/cloud-sdk:slim" failed: step exited with non-zero status: 1
Logs
NOTICE 2023-08-17T16:16:40.481718Z [protoPayload.serviceName: run.googleapis.com] [protoPayload.methodName: google.cloud.run.v1.Services.CreateService] [protoPayload.resourceName: namespaces/mobtakr-386219/services/next-js-cloud-run] [protoPayload.authenticationInfo.principalEmail: [] audit_log, method: "google.cloud.run.v1.Services.CreateService", principal_email: ""
NOTICE 2023-08-17T16:16:43.186355Z [protoPayload.serviceName: run.googleapis.com] [protoPayload.methodName: google.cloud.run.v1.Services.ReplaceService] [protoPayload.resourceName: namespaces/mobtakr-386219/services/next-js-cloud-run] [protoPayload.authenticationInfo.principalEmail: audit_log, method: "google.cloud.run.v1.Services.ReplaceService", principal_email: ""
DEFAULT 2023-08-17T16:16:48.573365Z 2023/08/17 16:16:48 Hello from Cloud Run! The container started successfully and is listening for HTTP requests on $PORT
INFO 2023-08-17T16:16:48.584791Z Default STARTUP TCP probe succeeded after 1 attempt for container "placeholder-1" on port 8080.
INFO 2023-08-17T16:16:48.705211Z [protoPayload.serviceName: run.googleapis.com] [protoPayload.methodName: v1] [protoPayload.resourceName: namespaces/mobtakr-386219/revisions/next-js-cloud-run-00001-9mg] Ready condition status changed to True for Revision next-js-cloud-run-00001-9mg.
INFO 2023-08-17T16:16:49.088717Z [protoPayload.serviceName: run.googleapis.com] [protoPayload.methodName: v1] [protoPayload.resourceName: namespaces/mobtakr-386219/services/next-js-cloud-run] Ready condition status changed to True for Service next-js-cloud-run.
I had a similar issue on 13.4.17
. It would start the nextjs server on a host that wasn't 127.0.0.1. Specifying HOSTNAME env var in my Dockerfile fixed it for me.
# Adapted from https://github.com/vercel/next.js/blob/canary/examples/with-docker/Dockerfile
# Install dependencies only when needed
FROM node:16-alpine AS deps
WORKDIR /app
# Install dependencies based on the preferred package manager
COPY package.json package-lock.json* ./
RUN npm ci
# Rebuild the source code only when needed
FROM node:16-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
# env vars
RUN rm .env*
COPY .env.production ./.env
# Next.js collects completely anonymous telemetry data about general usage.
# Learn more here: https://nextjs.org/telemetry
# Uncomment the following line in case you want to disable telemetry during the build.
ENV NEXT_TELEMETRY_DISABLED 1
RUN npm run build
# Production image, copy all the files and run next
FROM node:16-alpine AS runner
WORKDIR /app
ENV NODE_ENV production
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
COPY --from=builder /app/public ./public
# Automatically leverage output traces to reduce image size
# https://nextjs.org/docs/advanced-features/output-file-tracing
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 HOSTNAME 127.0.0.1
ENV PORT 3000
CMD ["node", "server.js"]
I had a similar issue on
13.4.17
. It would start the nextjs server on a host that wasn't 127.0.0.1. Specifying HOSTNAME env var in my Dockerfile fixed it for me.# Adapted from https://github.com/vercel/next.js/blob/canary/examples/with-docker/Dockerfile # Install dependencies only when needed FROM node:16-alpine AS deps WORKDIR /app # Install dependencies based on the preferred package manager COPY package.json package-lock.json* ./ RUN npm ci # Rebuild the source code only when needed FROM node:16-alpine AS builder WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . # env vars RUN rm .env* COPY .env.production ./.env # Next.js collects completely anonymous telemetry data about general usage. # Learn more here: https://nextjs.org/telemetry # Uncomment the following line in case you want to disable telemetry during the build. ENV NEXT_TELEMETRY_DISABLED 1 RUN npm run build # Production image, copy all the files and run next FROM node:16-alpine AS runner WORKDIR /app ENV NODE_ENV production RUN addgroup --system --gid 1001 nodejs RUN adduser --system --uid 1001 nextjs COPY --from=builder /app/public ./public # Automatically leverage output traces to reduce image size # https://nextjs.org/docs/advanced-features/output-file-tracing 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 HOSTNAME 127.0.0.1 ENV PORT 3000 CMD ["node", "server.js"]
doesn't work for me
i get 502 Bad gateway if i set ENV HOSTNAME 127.0.0.1
I have the same issue. After updating next.js to version 13.4.13, the Docker build stopped working, and the staging environment went down. I changed the HOSTNAME to 0.0.0.0. The build started working again, but dynamic routes with the following syntax stopped functioning: pages/blog/[slug].tsx
My dockerfile
FROM node:18-alpine AS base
# Install dependencies only when needed
FROM base AS deps
# Check https://github.com/nodejs/docker-node/tree/b4117f9333da4138b03a546ec926ef50a31506c3#nodealpine to understand why libc6-compat might be needed.
RUN apk add --no-cache libc6-compat
WORKDIR /app
# Install dependencies based on the preferred package manager (Yarn 2)
COPY package.json yarn.lock* .yarnrc.yml ./
COPY .yarn ./.yarn
RUN yarn install --immutable
# Rebuild the source code only when needed
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
# Next.js collects completely anonymous telemetry data about general usage.
# Learn more here: https://nextjs.org/telemetry
# Uncomment the following line in case you want to disable telemetry during the build.
# ENV NEXT_TELEMETRY_DISABLED 1
RUN yarn build
# If using npm comment out above and use below instead
# RUN npm run build
# Production image, copy all the files and run next
FROM base AS runner
WORKDIR /app
# ENV NODE_ENV production
# Uncomment the following line in case you want to disable telemetry during runtime.
# ENV NEXT_TELEMETRY_DISABLED 1
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
COPY --from=builder /app/public ./public
# Automatically leverage output traces to reduce image size
# https://nextjs.org/docs/advanced-features/output-file-tracing
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
CMD ["node", "server.js"]
Logs
Could this be related to these changes https://github.com/vercel/next.js/pull/53131 ?
i think yes
Any urls with [] (%5B, %5D) return a 404 error which includes the generated js files for any dynamic page
Having the same issues with ../../[slug].tsx route, tried specifying HOSTNAME in docker file but no success yet.
No one care about this :(
for me it's fixed with 13.4.19
Not working for me in 13.4.19. We have custom server setup (node:http library btw) that executes nextjs handler but after putting logs everywhere possible that handler just returns 404 (with custom 404 page) and does nothing. Another weird behaviour is that this is working when build and run on local machine - if we let pipelines and docker build it then it does not work.
Edit: Just ensured that it should be connected to dockerizing - when you run generated image then every route keeps returning 404 and its route logic (not even middleware!) is being executed
to be clear the missing ENV vars issue is what is fixed for me in 13.4.9 (thanks to https://github.com/vercel/next.js/commit/803bbe5c9388bb9b5af3b75ba6f1a76332e74112 -- I do not have ENV HOSTNAME 127.0.0.1
in Dockerfile), but I have some other issues now, namely https://github.com/vercel/next.js/issues/54120, which is already linked here
Had the same issue, and after spending almost a week in a lot of stress, I found out it was that nextjs version that broke everything.
The solution for me was going way back to "next": "13.4.1"
, and honestly I'm considering to never update that again in my life. Every week something breaks in a different place, and it's so stressful and frustrating. How a "patch" update can cause that much trouble is unbelievable to me.
I guess that's modern web development...
The same happened to me. Do you recommend going back to 13.4.1? I can't push to main for about a week now!
The same happened to me. Do you recommend going back to 13.4.1? I can't push to main for about a week now!
@mjad218, well in my case the 13.4.1
version seems to be working well, but I'm using the page structure instead of the new app structure, and I'm also making use of the api.
If your project has the same structure I would suggest trying out the 13.4.1
, or since this issue states that the bug happens in 13.4.13+
, I would try anything below it, like 13.4.12
or 13.4.11
.
I haven't try these version though, so I'm not sure if they work, nor if they have any important fixes, or even new bugs.
I tried 13.4.12
but the bug still exists. Currently, I am deploying the app with 13.4.1
. Just minutes and will see if it works
@hensou Same error even with 13.4.1
I also reverted to version 13.4.7, but the issues with the dynamic router are still present. Now I'm completely baffled.
@hensou Same error even with
13.4.1
@mjad218, do you happen to have set the HOSTNAME
in your Dockerfile
? If so try removing it.
Also, did you make sure to lock the version like "next": "13.4.12"
instead of "next": "^13.4.12"
?
@hensou Thanks mate, My yarn.lock file had 13.4.19
. I made sure it contained next@13.4.12
. Currently, I manage to deploy my app to Google Cloud Run.
Seeing this too in 13.4.19
when building an app in standalone mode. No HOSTNAME
set. My API route handlers when using redirects go to the internal IP address.
Seeing this too in
13.4.19
when building an app in standalone mode. NoHOSTNAME
set. My API route handlers when using redirects go to the internal IP address.
Same here, stuck at 13.4.12 unless you add ENV HOSTNAME 0.0.0.0 to your Docker
Seeing this too in
13.4.19
when building an app in standalone mode. NoHOSTNAME
set. My API route handlers when using redirects go to the internal IP address.Same here, stuck at 13.4.12 unless you add ENV HOSTNAME 0.0.0.0 to your Docker
That doesn't fix it for me. Still get ready started server on 172.17.0.2:3000, url: http://172.17.0.2:3000
It appears to me that NextJS primarily focuses its attention on catering to Vercel users, often relegating users of custom servers or Kubernetes to a lower priority.
A few months ago, there was an instance where they mishandled path detection on Windows, revealing a lack of thorough testing for various developer environments and this is their basic mistake on every release.
The frequent patch updates tend to introduce new issues, with many of them leading to problems like the notorious "not-found.js" errors. This situation seems quite perplexing. At this point, I've developed a strong suspicion that even if they manage to address this particular issue in version 13.4.20 or a similar update, it's likely that something else might inadvertently break in the process.
It appears to me that NextJS primarily focuses its attention on catering to Vercel users, often relegating users of custom servers or Kubernetes to a lower priority.
A few months ago, there was an instance where they mishandled path detection on Windows, revealing a lack of thorough testing for various developer environments and this is their basic mistake on every release.
The frequent patch updates tend to introduce new issues, with many of them leading to problems like the notorious "not-found.js" errors. This situation seems quite perplexing. At this point, I've developed a strong suspicion that even if they manage to address this particular issue in version 13.4.20 or a similar update, it's likely that something else might inadvertently break in the process.
I don't agree with you.
Vercel innovates and changes the front end scene. I see that with next 13
they introduced a lot of breaking changes and they have a lot of issues right now and I am sure they are constantly working on getting things right. ( They pushed a lot of great features btw, I am a big fan of App Router)
I even get it if they prioritize issues for Vercel users. They are a for-profit company at the end.
This does not justify the issues but I totally understand it.
It appears to me that NextJS primarily focuses its attention on catering to Vercel users, often relegating users of custom servers or Kubernetes to a lower priority. A few months ago, there was an instance where they mishandled path detection on Windows, revealing a lack of thorough testing for various developer environments and this is their basic mistake on every release. The frequent patch updates tend to introduce new issues, with many of them leading to problems like the notorious "not-found.js" errors. This situation seems quite perplexing. At this point, I've developed a strong suspicion that even if they manage to address this particular issue in version 13.4.20 or a similar update, it's likely that something else might inadvertently break in the process.
I don't agree with you.
Vercel innovates and changes the front end scene. I see that with
next 13
they introduced a lot of breaking changes and they have a lot of issues right now and I am sure they are constantly working on getting things right. ( They pushed a lot of great features btw, I am a big fan of App Router)I even get it if they prioritize issues for Vercel users. They are a for-profit company at the end.
This does not justify the issues but I totally understand it.
Yeah, I understand your point. The App router is functional, but there are some concerns. For instance, the enforcement of edge runtime on middleware, the absence of shallow routing, and an excess of automatic processes that developers can't control, like caching. There are a few other issues that currently escape my memory, but collectively they obstruct my team and me from making further progress.
Claiming to have a stable production environment while consistently introducing errors with each patch update is concerning. While it's reasonable to prioritize Vercel deployments, it's crucial not to impede other users with frequent errors or bugs in every patch.
Certainly, NextJS boasts impressive features that set it apart from other frameworks, which is partly why we've chosen to use it. However, the recent approach of facilitating IPv6 support at the expense of crippling the Kubernetes experience for users since version 13.4.12 is not a favorable strategy.
I get your point. You need to stay within a working version and don't update next
until you make sure the issues are solved and you test your app locally and maybe have a staging environment.
I get your point. You need to stay within a working version and don't update
next
until you make sure the issues are solved and you test your app locally and maybe have a staging environment.
Yes that's another issue for me Mohamed. Because the version that works for me is 13.4.12 and it's working in a bad way. We get a lot hydration error from Radix libraries saying id mismatch from the server, It does work though but it breaks another thing thats working with "react-use-gesture" library. And the page I am working on is in production yet we continue to wait ofc.
I get your point. You need to stay within a working version and don't update
next
until you make sure the issues are solved and you test your app locally and maybe have a staging environment.Yes that's another issue for me Mohamed. Because the version that works for me is 13.4.12 and it's working in a bad way. We get a lot hydration error from Radix libraries saying id mismatch from the server, It does work though but it breaks another thing thats working with "react-use-gesture" library. And the page I am working on is in production yet we continue to wait ofc.
I currently don't have problems with 13.4.12
. Actually, you may be able to solve the hydration errors without updating next js.
I managed to solve most of the hydration issues by client rendering the Date components
and actually using a useEffect
hook to set the date after the initial render.
I don't know the libraries you are using but I assume updating next won't solve the hydration errors as these libraries are the ones that should adopt the breaking changes of next 13
.
One way to solve the hydration issues is to dynamic import
the components that have these issues and set ssr: false
.
you may need to dig deeper and solve the hydration issues
and some extensions may cause such hydration problems, So you may disable all extensions while testing/developing
The issue fixed for me after downgrading nextjs to 13.3.4
The issue fixed for me after downgrading nextjs to 13.4.9
and set HOSTNAME
in env variables.
The new versions not reading the HOSTNAME
variable.
Before downgrading:
After downgrading:
Fixed my API route redirect for now by building the URL using the request headers (which I think was mentioned in a different thread)
const url = new URL(req.headers.get('origin') || '')
NextResponse.redirect(url, 302)
I have to downgrade to next@13.4.12
and set ENV HOSTNAME localhost
in Dockerfile to make my app run normally. Just wait for fixing this bug on the next stable release.
I had a similar issue and posted this question and answer on Stack Overflow
Due to recent changes, you now need to add this line to your Dockerfile:
ENV HOSTNAME "0.0.0.0"
I don't know for sure, but if I had to guess, I think it's related to the change on this line of the pull request: https://github.com/vercel/next.js/pull/53131/files#diff-3a7de5f9ca3729cdc0a041e9d4c22391754e702ba49ba230daf55730bdc70d99R1975
I noticed that 13.4.13
was working, but 13.4.15
was not. This code was a part of the 13.4.15
release.
@m4salah made a pull request that fixed the issue in the docs for new projects using the with-docker example. Projects already using Docker and NextJS will need to add that line.
The full, working Dockerfile example now includes that as the second-to-last line. This is the current snapshot of that example:
FROM node:18-alpine AS base
# Install dependencies only when needed
FROM base AS deps
# Check https://github.com/nodejs/docker-node/tree/b4117f9333da4138b03a546ec926ef50a31506c3#nodealpine to understand why libc6-compat might be needed.
RUN apk add --no-cache libc6-compat
WORKDIR /app
# Install dependencies based on the preferred package manager
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 yarn global add pnpm && pnpm i --frozen-lockfile; \
else echo "Lockfile not found." && exit 1; \
fi
# Rebuild the source code only when needed
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
# Next.js collects completely anonymous telemetry data about general usage.
# Learn more here: https://nextjs.org/telemetry
# Uncomment the following line in case you want to disable telemetry during the build.
# ENV NEXT_TELEMETRY_DISABLED 1
RUN yarn build
# If using npm comment out above and use below instead
# RUN npm run build
# Production image, copy all the files and run next
FROM base AS runner
WORKDIR /app
ENV NODE_ENV production
# Uncomment the following line in case you want to disable telemetry during runtime.
# ENV NEXT_TELEMETRY_DISABLED 1
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
COPY --from=builder /app/public ./public
# Automatically leverage output traces to reduce image size
# https://nextjs.org/docs/advanced-features/output-file-tracing
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
# set hostname to localhost
ENV HOSTNAME "0.0.0.0"
CMD ["node", "server.js"]
Hope this helps others!
@LukeSchlangen this fixed it for me on 13.4.19
. You're a life saver!
Verify canary release
Provide environment information
Which area(s) of Next.js are affected? (leave empty if unsure)
Standalone mode (output: "standalone")
Link to the code that reproduces this issue or a replay of the bug
https://github.com/vercel/next.js/blob/canary/examples/with-docker/Dockerfile
To Reproduce
See description
Describe the Bug
I'm using dockerfile from the examples. After upgrading to version 13.4.13-13.4.16, my application stopped working properly. calling the 'router.push' function results in hard navigation
in middleware redirect before: https://my-site.com/some-path now: http://172.18.0.6:3000/some-path
Expected Behavior
13.4.12 behavior
Which browser are you using? (if relevant)
No response
How are you deploying your application? (if relevant)
self-hosted