How can I use Next.js over HTTPS instead of HTTP?

[m-abdelwahab]

I want to make a request to an API, however, it must be done over HTTPS. I want to configure next so that the app is running at https://localhost:3000 and not http://localhost:3000. Can someone help me with this?

[waptik]

@m-abdelwahab check this out https://gist.github.com/cecilemuller/9492b848eb8fe46d462abeb26656c4f8 or mkcert

[PlopTheReal]

Once you have certificates, based on the following example: https://github.com/zeit/next.js/tree/canary/examples/custom-server
you will have something like this:
/server.js:

var https = require('https');
var fs = require('fs');

const next = require('next')
const port = parseInt(process.env.PORT, 10) || config.getPort()
const dev = process.env.NODE_ENV !== 'production'
const app = next({ dev, dir: __dirname })
const handle = app.getRequestHandler()


var options = {
    key: fs.readFileSync('ssl.key'),
    cert: fs.readFileSync('ssl.crt'),
    ca: [fs.readFileSync('root.crt')]
};

app.prepare().then(() => {
    https.createServer(options, (req, res) => {
        // handle ....
    }).listen(port, err => {
        if (err) throw err
        console.log(`> Ready on localhost:${port}`)
    })
})

[mi-na-bot]

disagree with both these comments. Pushing SSL up the the proxy layer is a very good choice, you would be hard pressed to find production grade apps worth their salt, that terminal SSL within app land. If you're upset Vercel is feeding you an amazing free product with incredible support ... thats actually unfair. Rather than you stating they should do ALL the hard work for you.

This has nothing to do with production or a CDN/proxy. People just want a way to supply next dev with a certificate to run SSL to develop stuff that the browser requires SSL for (such as service workers). Making a custom server that runs on https is literally trivial--a hint that adding support directly to next dev would be trivial.

[skrenes]

@andrewmclagan I agree with you about production instances, but what @MinervaBot said is totally on point. They should support it in dev and state in documentation why they don't support it in production. Even disclosing why in a couple sentences goes a long way to curtail developer frustration and serves to educate the public. Having said that, it is an open source project, so I guess any of us could submit a PR to at least amend the documentation.

[drewtwo]

I am just learning next.js and this issue has been incredibly annoying while trying to implement oauth against a service that requires https. I was able to get it working using a custom-server but that isn't a good solution and doesn't work with some oauth libraries. Kind of hard to believe they don't support running https without jumping through additional hoops.

[KorbisInc]

Sometimes development isn't fun if everything is too simple 😉 So NextJS must follow the webdev trend of having some nice pain points. Keeps you on your toes!

[steowens]

disagree with both these comments. Pushing SSL up the the proxy layer is a very good choice, you would be hard pressed to find production grade apps worth their salt, that terminal SSL within app land. If you're upset Vercel is feeding you an amazing free product with incredible support ... thats actually unfair. Rather than you stating they should do ALL the hard work for you.

From a security standpoint any production grade application that does not support end to end encryption all the way to the running process should never be authorized for release into production. Perhaps there is a reason why Node.js tends to get breached a lot more than other frameworks such as Java or Golang. https://www.mindinventory.com/blog/nodejs-security-best-practices/

[niedfelj]

Why doesn't next have a config to force ssl? I had to setup a separate node server.js just to use the express force ssl middleware and then I lose the next server optimizations

[abdulbasit010]

@niedfelj Any solutions so far ?
I am stuck in the same problem.

[Adrien-D]

@abdulbasit010 Same here, keep me updated if you found a solution

[jackHedaya]

I've just been using a custom server for development but deploying using serverless.

[cdpark0530]

This is unbelievable when I consider that one of Nextjs' powerful features and goals(based on where it's been going) is dev-setup free.

[ken107]

Vercel invites you to sign up for the cloud hosting solution

[niedfelj]

I opened a PR for this, but no one has commented. It's not ready for merge, but wanted some feedback on whether there's interest before I convert to typescript

#17654

[jaxomlotus]

Definitely interested. This is a huge gap in usefulness without this.

[gl0gl0]

Also interested 🙋🏻‍♀️

[abdulbasit010]

interested in force ssl redirect

[tsongas]

Interested in this and also redirecting naked domain to www subdomain.

[niedfelj]

@tsongas @abdulbasit010 I think the best solution is probably putting nginx in front of it, I wrote up some samples of this for the nginx heroku buildpack that should help you:

https://github.com/heroku/heroku-buildpack-nginx#force-ssl

You can also do a custom server but you lose some of the next serve functionality, here's what that would look like:

const express = require('express')
const next = require('next')

const secure = require('express-force-https')
const dev = process.env.NODE_ENV !== 'production'
const app = next({ dev })
const handle = app.getRequestHandler()
const port = process.env.PORT || 3000

app
  .prepare()
  .then(() => {
    const server = express()

    // redirect to SSL
    if(!dev) { 
      server.use(secure)
    }

    server.get('*', (req, res) => {
      return handle(req, res)
    })

    server.listen(port, err => {
      if (err) throw err
      console.log('> Ready on http://localhost:' + port)
    })
  })
  .catch(ex => {
    console.error(ex.stack)
    process.exit(1)
  })

[jasonadkison]

One way to enable https during local development is to use something like local-ssl-proxy.

[SomervilleTom]

This approach works if self-signed certs and "localhost" in the resulting https URL is enough. A project that uses authentication with a third-party provider like "Auth0" will have issues with this, because the third party provider typically allows only actual (not self-signed) certs for its callbacks ("https://localhost:3000" doesn't work, "https://sub.your.domain.com:3000" does work).

I'm pretty sure that a more invasive (to nextjs) approach is currently required if actual certs (issued by a recognized authority) and actual URLs are needed. For those doing remote development (such a when using the "Remote SSH" extension of vscode), changes to 'launch.json' are needed so that a development browser correctly connects back to vscode.

I've had better luck doing the following:

1, Patch the 'startServer.js' file deployed with next.js (I know, I know. But the consequences, at least for me, are much less painful than the local-ssl-proxy approach described here)
2. Add "PORT=12345" as needed to the "dev" entry in "package.json" and adjust "launch.json" to match
3. Add "PORT=54321" (different from the dev port) to the "start" entry in "package.json". When the two ports are different, then you don't need to stop the pm2 service in order to do development using the dev server and port.
4. Run yarn build to deploy changes
5. Use pm2 using something like 'pm2 --update-env start "yarn start" --name your-app-name --time' so that a deployed app is always running
6. Configure a reverse proxy in whatever subdomain config (in "/etc/nginx/sites-available/") you choose for your external name.

I use "LetsEncrypt", which means I use "certbot", to manage all the certs on my server(s) -- most of the tedium of cert management is automated. The needed changes in the nginx config are already done automagically by certbot, so I just add a 'location' directive with a reverse proxy configuration to the desired config. An example looks like this:

location / {
  proxy_pass https://12.34.56.78:54321;
  proxy_buffering off;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header X-Forwarded-Port $server_port;
}

Of course, you have to use real values relevant to your server for all of the above.

So far as I can tell, I have access to the full next.js behavior in both dev and after deployment. I can use third-party providers in both contexts. All this is self-hosted, so it is straightforward to conform to corporate server and configuration constraints.

I love and appreciate the power and benefits of next.js, it's a huge improvement over the old CRA stuff it replaces.

It would be even more awesome if next.js would listen to the almost-standard convention of using "HTTPS=true" in the environment to specify an https (rather than http) server in the "dev" and "start" entries of "package.json" -- then I could ditch the kludgy "startServer.js" patch.

[mi-na-bot]

You could easily supply a CA signed certificate to the startServer.js; it makes no difference to the server whether the certificate is signed by a valid authority.

[SomervilleTom]

@MinervaBot: Oh, for sure. The motivation for the patch is so that an https server is started from the "dev" script.

[SomervilleTom]

I'm pretty sure that an https server is needed during dev so that calls to third-parties such as Auth0 have an https server with an actual domain to provide as a callback URL. This was an issue when I first started using React + CRA in vscode -- it took me some time to work out how to get things going so I could use the IDE to develop my side of exchanges with Auth0.

The "React + nextjs + material" combination is MUCH better in vscode. No more browser complaints, no more issues with browser reload (hard or soft), and so on.

This toolset is WAY better.

[mi-na-bot]

@SomervilleTom Right, I am saying you can give the CA signed cert to the dev server too, and add an entry for yourdomain.com -> 127.0.0.1 in hosts. That way it looks 100% real.

I switched to Next.js from Gatsby and feel the same way, it is pretty nice except for the occasional silly frustration like this.

The flavor of problems for "dev HTTPS required" have been varied for me. Perhaps the most annoying was creating a PWA, where the browser ardently insists on a CA valid certificate (even just to test). I solved this by adding my self-signing CA to the browser trust store. Kind of crappy though because that trust leaks to a lot of places.

Perhaps the lightest was a third party overlay JS widget that wouldn't run at all without HTTPS, but it had no way to care whether the cert was good.

With third parties the problem mostly boils down to CORS policy or where an OAuth redirect is allowed to target. Many vendors will now allow you to add http://localhost:3000 for either, it just makes life easy for almost 0 security risk. Someone would have to be attacking themselves from their own computer, so are already owned!

When using Storyblok CMS preview mode, it was kind of a pain not having the dev server on HTTPS using it. Since it framed in the page from the dev server, it really clashed with a the Storyblok having a good content security policy. Mostly aesthetic, but also really annoying if working on untrusted WiFi.

[jackHedaya]

What needs to be done for this to become a thing?

[xtealer]

Do some memes ?)

[steowens]

stop using nextjs until the team gets some security experience under their belt

[mi-na-bot]

I know this is kind of a silly thing, but I have a client using a third-party JS that basically does nothing when rendered without SSL which is quite difficult to test. Using a custom server isn't really worth it for us at this time, but having a quick and easy way to add a self-signed certificate would be super handy.

[jackHedaya]

@Timer I see the pull request was closed for further discussion. Will the discussion happen on this thread or is it between maintainers elsewhere?

[binajmen]

In order to keep the next server as it is (I don't like the idea of losing the next server optimizations), but still access the GeoLocation API from my browser in my local environment (and the other APIs that are available only in secure contexts (HTTPS), I'm using ngrok which works flawlessly (and is free for normal usage):

$ ngrok http 3000             👈  replace with the port you are using locally
ngrok by @inconshreveable                                                                        (Ctrl+C to quit)
                                                                                                                 
Session Status                online                                                                             
Account                       xxx (Plan: Free)                                                              
Version                       2.3.35                                                                             
Region                        Europe (eu)                                                                        
Web Interface                 http://127.0.0.1:4040                                                              
Forwarding                    http://xxxxxx.eu.ngrok.io -> http://localhost:3000                           
Forwarding                    https://xxxxxx.eu.ngrok.io -> http://localhost:3000   

You can then access https://xxxxxx.eu.ngrok.io and have fun 😉. On top of that, people outside of your network can access your app.

[astriskit]

this is a cool solution

[justyn-clark]

ngrok is cool, love it, but you need a paid plan for custom domains if you have cookie dependencies between apps.

[Snouzy]

cors problems incoming ;p

[EliasTouil]

This is useful if you are using chrome and want a quick workaround

Got to
chrome://flags/#allow-insecure-localhost

Insert the URL(s) of your development environment

relaunch chrome

This allowed me to test getUserMedia with the camera, I have not tested it for other use cases.

Cheers

[gloyens]

Brilliant! Worked perfectly for me with Next Auth. 👍

[felixmeziere]

Facebook login now only works over https, it would be really good to have a simple way to run local Next.js on https://localhost:3000 :)

[thebetterjort]

Looking for a solution, I have 5 different nextjs apps on the same server and I'm really struggling to handle all of them without SSL without a proxy (which has proven to be difficult to use with nextjs).

[NoelBaron]

For everyone complaining about running next on https, there is an easy solution. I don't know if it works with NextAuth.js but out-of-the-box next should be fine.

You'll need brew, install mkcert with brew (or manually if necessary) and you'll need to create a certificate with mkcert

Then you may update your host file, usually /etc/hosts, with a new host that points https://local.mydomain.com to your localhost.

// package.json
"start:local": "PORT=4000 node ./server-local.js",

//./server-local.js

var https = require('https');
var fs = require('fs');
const path = require('path')
const { parse } = require('url');

const next = require('next')
const port = parseInt(process.env.PORT) || 4002
const dev = true;
const app = next({ dev, dir: __dirname })
const handle = app.getRequestHandler()

var options = {
  key: fs.readFileSync('certs/local.mydomain.com.key.pem'),
  cert: fs.readFileSync('certs/local.mydomain.com.pem'),
};

app.prepare().then(() => {
  https.createServer(options, (req, res) => {
    const parsedUrl = parse(req.url, true);
    handle(req, res, parsedUrl);
  }).listen(port, err => {
    if (err) throw err
    console.log(`> Ready on localhost:${port}`)
  })
})

[skrenes]

@NoelBaron I had a similar custom server, but there are problems with this approach. Here's another issue I created detailing one of the problems: nextauthjs/next-auth#1324 (comment)

[dsmileybrainly]

There are a lot of reasons developers need https support for local testing. Losing server optimization is not an option, especially in this new era of Core Web Vitals testing that absolutely requires static optimization support. Developers should not be forced to chose between https and a server that works (people answering this thread should point out that a custom server comes with a cost):

Before deciding to use a custom server, please keep in mind that it should only be used when the integrated router of Next.js can't meet your app requirements. A custom server will remove important performance optimizations, like serverless functions and Automatic Static Optimization.

We'll implement our own workaround using a reverse proxy, but we'll also have to implement browsersync or similar to not degrade the developer experience (we don't want them to have to manually refresh).

[mi-na-bot]

You can use a custom server for testing/hot reload without necessarily changing how you deploy next.js, or preventing you from using Vercel. Just the custom server itself will not run on Vercel, and certain features will not work when you are running the custom server instead of next start or dev.

[steowens]

this has been most informative. We were evaluating migrating to next.js but from a security perspective it means that we cannot use end to end encryption in development which implies that our ability to actually develop the way we deploy is compromised, and there will be a strong push to use hacks such as nginx proxy and other stuff in the pods. Not ideal from a security perspective.

[kuhlaid]

If you are not interested in setting up a custom server (which will break the integrated NextJs router) and are cool with running your app locally on a port other than 3000 (which is the default NextJs port), here is what worked for me (these instructions assume using Windows WSL terminal, and yarn commands instead of npm).

In your Linux terminal, change to your project directory and then copy and paste the following command to setup the self-signed certificate (which creates a localhost.crt and localhost.key file within your project):

openssl req -x509 -out localhost.crt -keyout localhost.key \
  -days 365 \
  -newkey rsa:2048 -nodes -sha256 \
  -subj '/CN=localhost' -extensions EXT -config <( \
   printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")

• sudo mkdir /usr/local/share/ca-certificates/extra # see https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate for additional information

• sudo cp localhost.crt /usr/local/share/ca-certificates/extra/localhost.crt

• sudo update-ca-certificates

• yarn local-ssl-proxy # here we install a proxy for the SSL connections

• NODE_TLS_REJECT_UNAUTHORIZED=0 # this needs to be added to the .env file to ignore unsigned certificates on localhost (only include this on the development .env file, not production)

• In the package.json file, I created a dev-ssl startup script and assigned the command (local-ssl-proxy --source 8080 --target 3000) & next dev as shown below

...
"scripts": {
    "dev-ssl": "(local-ssl-proxy --source 8080 --target 3000) & next dev",
...

• NEXTAUTH_URL=https://localhost:8080 # again in the .env file make sure any references to localhost use the HTTPS URI and source PORT (which in this case I have set to 8080 in the dev-ssl startup command)
• yarn dev-ssl # this will start up the proxy server to send requests to https://localhost:8080 to http://localhost:3000 (which is what our NextJs app will be running on) and then start the NextJs server next dev

[justyn-clark]

This appears to be working for me.

[blainegarrett]

I previously had the custom server solution in place and eliminated it via this approach. This allowed me to get rid of express, ts-node, and nodemon to supplement reloading. Thank you

[theGOTOguy]

Thank you! Works great with Auth0 on Ubuntu.

[hugotox]

BTW, custom server does not break NextJS router. Please don't spread misinformation

[cdpark0530]

+1 for placing local-ssl-proxy in front of main command next as placing it behind and using pipe would result hiding nextjs logs.

[kyle-gonzales]

This article was greatly able to help me:

https://ilango.hashnode.dev/serving-a-nextjs-application-over-https-in-localhost

Just make sure to move localhost.pem and localhost-key.pem from C:\Windows\system32 to /certs of your project

[SomervilleTom]

I appreciate your attention.

I cobbled together an approach that appears to be working and avoids the several restrictions of static deployment. I realized my earlier requirement to use Apache as my public-facing http service was a real barrier. I therefore migrated my underlying server to use nginx instead of Apache.

My several servers (each an AWS EC2 instance running Rocky Linux) each use certs from LetsEncrypt (certbot). These work fine and I have other infrastructure to manage them. I therefore need to continue using them and certbot.

In a more perfect world, nextjs would pay attention to the HTTPS=true environment variable just as it currently pays attention to the PORT=1234 environment variable. Since this is not currently the case, I chose to patch the 'start-server.js' file deployed with nextjs so that it starts an https, rather than http, server. I recognize the risks of this -- in my case, the benefits greatly exceed the increased hassle.

The development system I manage and use has multiple developers, multiple apps, sits behind an AWS security group, has both a public and private (to AWS) IPV4 address, and has a public domain name. Opening ports and mucking with domain names is therefore not a lightweight operation. I therefore use a convention that each developer has a single port used by that developer while running vscode, regardless of which app the developer is working on. Each developer also has up to 99 ports, one per app, so that full external https access can be exercised on each app prior to deployment on an actual public-facing server.

As a result, a particular app has one port used by yarn dev and a different port used by yarn start/yarn build. I configure package.json to use the PORT=... in its "scripts" section, and I configure 'launch.json' to listen on the port assigned to the 'dev' entry in scripts.

I configure pm2 to run the deployed version of each app, and I've configured nginx as a reverse proxy for external access using a specific (sub) domain name.

As I said above, this all seems to be working now. I'm very impressed with the behavior and performance of next.js, and I'm particularly impressed with the documentation. Although I'm still climbing a learning curve, it's been enjoyable and satisfying so far.

The combination of MaterialUI + react + next.js + nginx is already working WAY WAY better than the original combination (MaterialUI' + react+create-react-app+Apache`) it replaces.

[none1192827727277]

get request can have a body as parameter and can i use getserversideprops but i have to pass body

[none1192827727277]

I want call get request to an API, however, it need to pass body as parameter but not pass into header or params

[agent1ve]

The latest Next.js version release 13.5.1 has an experimental flag for the dev server to run over https.

See the release notes under "Other Improvements"

• Update to latest Next.js via: npm i next@latest react@latest react-dom@latest eslint-config-next@latest
• Update package.json script for "dev" to: next dev --experimental-https

Uses "mkcert" and stores certificates under your project root in a folder named "certificates" where it will store 2x certs: "localhost-key.pem" and "localhost.pem"

As a sanity test, I ran my local dev server with the --experimental-https flag and set an FB/Instagram App's OAuth callback value to "https://localhost:3000/api/auth/callback". Instagram provided the working token back to the localhost. This did not work previously since the FB developer portal does not allow OAuth callbacks that aren't over https.

[mustafademiray1]

I attempt to utilize all HTTP proxy servers for my setup. OpenLiteSpeed(OLS) is much faster than Nginx and Apache, and it comes with an admin panel. The speed ranks as OLS > Nginx > Apache. However, OLS doesn't work with Authentication systems and internationalization systems. If you don't need them, you can use OLS. OLS doesn't work with them because these systems use HTTP headers and client information settings that apply CSP policies.

These steps are challenging for independent developers who want freedom.

[SomervilleTom]

@mustafademiray1: I hear you. :)

I haven't needed any internationalization systems, so I can't speak to that. I use 'Auth0' for authentication and authorization, and the 'Auth0' interactions require an https connection with a real cert (I use 'certbot'). That's why I do the kludgy patch I described above. I don't doubt that it's slower than OLS, but at least it works -- I'll worry about performance later.

These steps are challenging for independent developers who want freedom.

Indeed! For a variety of reasons, hosting everything at Vercel is not an option for me. It's been challenging for sure, but as far as I can tell it works.

Oh, and FWIW -- I use 'vscode' with its "Remote SSH" extension for all my development, and it seems to work fine with my patch. While I'm working on a given React app, I use a custom port (5099) -- I configure that in the "dev" entry of 'package.json'. I deploy to a different port (5002). There are sometimes multiple developers active on my server, and the environment is configured to use developer-specific ports. So a different developer working on the same 'next.js' app might use 6099 for dev and 6002 for deployment. The 'launch.json' file used by 'vscode' has to use the dev port (5099 for me), and that's not a heavy lift. I also have some magic in '/etc/hosts', but I don't think that's relevant here.

Oh -- and of course there's the AWS security group and elastic IP stuff to manage. All this port stuff has to be kept consistent in both the server firewall ('firewall-cmd') and the relevant AWS security group(s).

I know how to configure nginx to handle all this, and it all seems to work as far as I can tell.

It is, however, truly challenging to know that I'll have to change my patch (to 'start-server.js') any time that 'next.js' modifies that file.

That's why I would very much prefer the 'next.js' team to more gracefully handle https for the dev and build server for self-hosted installations like mine.