Set up HTTPS for self-hosted n8n with tailscale

I disconnected my hostinger n8n automation server thinking that it would be easy to self-host it on my linux server.

But as with all things that you think are easy, it wasn't.

Spinning up the n8n server was in fact very easy. All I had to do was create a docker compose file following the instructions from (insert n8n documentation).

And it was up and running with a single command

docker compose up -d

But when I went to rebuild my automations I couldn't connect with my google account without HTTPS.

Here are the Steps to Self-Host N8N

Step 1: Create a Project

1. Go to console.cloud.google.com
2. Click the project dropdown at the top → New Project
3. Name it something like n8n-automation → Create
4. Make sure that new project is selected in the top nav

Step 2: Enable All the APIs You Need

Go to APIs & Services → Library and search for and enable each of these:

The Google nodes available in n8n include: Google Calendar, Google Contacts, Google Docs, Google Drive, Google Gmail, Google Sheets, Google Slides, and Google Tasks. You'll need to enable the corresponding API for each one you want to use: n8n

Search each one, click it, and hit Enable. You can always come back and add more later.

Step 3: Configure the OAuth Consent Screen

Open the left nav and go to APIs & Services → OAuth consent screen.

Select Get started on the Overview tab. Enter an App name (e.g. "n8n") and a user support email. n8n

For Audience/User Type:

• If you have a Google Workspace org, pick Internal — this skips verification and is simpler
• If you're using a personal Gmail account, pick External

If your app User Type is External, go to the Audience page and add your email to the list of Test Users. Without this, the OAuth flow will fail with an "Access denied" error. n8n

Step 4: Create the OAuth Client ID

Go to APIs & Services → Credentials → + Create Credentials → OAuth client ID.

Set Application type to Web application and give it a recognizable name. n8n

Now here's the critical part — the redirect URI:

Before you can fill this in, go to n8n first:

1. In n8n, go to Credentials → New Credential
2. Search for any Google service (e.g. "Google Sheets OAuth2 API")
3. Open it — you'll see an OAuth Redirect URL field, copy that value

It will look like:

https://your-n8n-domain.com/rest/oauth2-credential/callback

Paste that URL into the Authorized redirect URIs field in Google Cloud Console, then click Create. n8n

If you're running n8n on your local machine and you're accessing it on your local machine, Google allows localhost as a valid redirect URI — your URL will look like http://localhost:5678/rest/oauth2-credential/callback. n8n

After clicking Create, Google gives you a Client ID and Client Secret — copy or download these. You'll use them repeatedly in the next part.

Step 4: Detour OAuth with Tailscale

If you're like me and you're trying to run your own n8n on your own local linux server, you will need to follow some extra steps.

When I tried to set it up with localhost it refused to connect.

As I'm writing this I feel like I should just keep use the n8n instance that's running on Hostinger. But since I started already I have to see it through to the end and find out if it'll actually work.

Anyways, let's keep going.

Tailscale can set up HTTPS using its own MagicDNS certificates, no separate reverse proxy needed.

1. Enable HTTPS certs for your tailnet (one-time, in the Tailscale admin console):
Go to your Tailscale admin panel → DNS tab → enable HTTPS Certificates.

2. Check your tailscale status
Run on the server:

tailscale status

You'll get something like 100.x.x.x server-name user-name@ linux -

To get your full MagicDNS name will be ubuntu-server-20260519.<tailnet-name>.ts.net. To get the exact full form, run:

tailscale dns status

or check the Machines page in the Tailscale admin console — click your server and it'll show the full DNS name directly under the machine name.

3. Use Tailscale Serve to proxy HTTPS → your n8n port

sudo tailscale serve https:<port> / http://localhost:<port>

This gives an HTTPS to the port that you're running your app on. It can be run for any docker container apps that you want on HTTPS.

4. Update your n8n environment variables
In your docker-compose or run command, set:

- N8N_HOST=${N8N_HOST}
- N8N_PORT=${N8N_PORT}
- N8N_PROTOCOL=${N8N_PROTOCOL}
- NODE_ENV=production
- GENERIC_TIMEZONE=America/New_York
- TZ=America/New_York
- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
- N8N_SECURE_COOKIE=false
- N8N_EDITOR_BASE_URL=${N8N_EDITOR_BASE_URL}
- WEBHOOK_URL=${WEBHOOK_URL}

Then restart the container:

docker compose down && docker compose up -d

5. Now check your n8n credential panel
When you create a Google credential in n8n now, the OAuth Redirect URL field should show:

https://my-server.tailnet-name.ts.net/rest/oauth2-credential/callback

6. Register that exact URL in Google Cloud Console under Authorized redirect URIs.

7. Access n8n from your laptop at https://my-server.tailnet-name.ts.net and do the "Sign in with Google" flow from there.

Part 2 — Setting Up Credentials in n8n

The key insight here: you only need one OAuth app in Google Cloud. You can reuse the same Client ID and Client Secret across all Google service credentials in n8n. Mike Murphy Co

For each Google service you want to use, do this:

1. In n8n, go to Credentials → New
2. Search for the service (e.g. "Google Sheets OAuth2 API")
3. Paste in your Client ID and Client Secret
4. Click Sign in with Google → authenticate → grant permissions

Repeat this for each service: Google Sheets, Google Drive, Google Docs, Gmail, Google Calendar, etc. Same Client ID/Secret each time, just a new credential record in n8n.

Common Gotchas

These steps are included above but they are easily missed so if you're running into errors it could be that you missed a step.

• Redirect URI mismatch — the URL in Google Cloud must exactly match what n8n shows, including http vs https
• "Access denied" / 403 — you forgot to add your Gmail as a Test User (only relevant if User Type is External)
• "This app isn't verified" warning — normal for personal/internal apps, just click Advanced → Go to [app name] to proceed
• Using different emails for the test users, consent screen, and authentication causes silent failures — stick to one email throughout Growwstacks
• API not enabled — if a node fails, double-check you enabled that specific API (e.g. forgot to enable the Docs API)

HTTPS for all Docker Containers with Tailscale

I also have other containers running including apps like Immich for Photos and Navidrome for music.

I decided to give them HTTPS too with the following command

sudo tailscale serve https:<port> / http://localhost:<port>

Nothing about how those apps work internally needs to change — they still think they're running on plain HTTP locally, Tailscale is just wrapping the connection in TLS on the way to my laptop.

Quick note if you go down this road: I briefly considered putting everything under one hostname with different paths instead of different ports — like /photos for Immich, /music for Navidrome.

Don't do this unless the app specifically supports being served from a subpath. Most self-hosted apps assume they live at the root of a domain, and putting them under a path breaks their internal links and API calls in ways that are annoying to debug. Ports, not paths, kept everything working with zero app-side changes.

What I'd tell past-me

If you're self-hosting on a machine without a public IP, accessed over Tailscale, the "just use localhost" advice in most tutorials doesn't apply to you — that advice assumes your browser and server are the same machine. The moment you're connecting remotely, you need a real address your browser can reach, and Google needs that address to be HTTPS.

Tailscale Serve turned out to be the easiest way to get there, and once I set it up for n8n, doing the same for my other containers was basically free — same command, different port, each time. My whole home server setup is a little more secure now, and it only happened because Google OAuth refused to cooperate until I figured out why.

Anyone else running a fully headless home server hit this same wall with OAuth? Curious what else people have had to work around.