Share a project externally with a public link and optional password

TL;DR — To share a result with someone outside your company, the simplest reliable method is to publish it at a public web address and send that link. If the content is sensitive, put it behind HTTP Basic Auth (a browser username/password prompt) before you share it. Reading time: ~5 min

Goal

When you finish, an external person will be able to open a link in their browser and see the result without needing your company VPN, internal account, or office network access.

Prerequisites

• The URL you want to share, or access to the system where the result is hosted
• Permission to change either your hosting settings or your web server settings
• If you want a branded link: your DNS provider login (the service where your domain records are managed)
• If you want password protection: a username and password you are comfortable sending to the recipient separately
• Browser access to your hosting provider dashboard, or server access if your agency told you to use nginx or Apache
• If using nginx on a server: nginx installed and openssl available — check with:

nginx -v
openssl version

Steps

Step 1: Decide whether you need a plain public link or a password-protected link

Use this rule:

• If the result is safe for anyone with the link to view, use a plain public link.
• If the result includes client data, drafts, pricing, or anything non-public, use a password-protected link.

What you should see when this step succeeds: you have chosen one of these two paths before changing anything.

Step 2: Find or create the public URL

Use the dashboard path your hosting provider gives for site URLs. In most providers, this is one of these patterns:

• Hosting dashboard → Project/Site → Domains
• Hosting dashboard → App/Service → Networking
• Hosting dashboard → Environment/Production → URL

If a public URL already exists, copy it exactly, including https://.

If you want to use your own domain, add a DNS record in your provider's dashboard (for example, in a DNS area often named "DNS", "Domains", or "Records") using the exact values your host shows you. The two most common cases are:

Then attach that domain in your hosting dashboard using the exact menu path your provider exposes, usually:

• Hosting dashboard → Project/Site → Domains → Add domain

Enter:

share.yourdomain.com

What you should see when this step succeeds: the domain appears in your host's domain list, usually with a status such as "connected", "active", or a green check.

Step 3: Turn on HTTPS if it is not already on

In your hosting dashboard, use one of these common paths:

• Project/Site → Domains → share.yourdomain.com → Enable HTTPS
• Project/Site → Security → TLS/SSL (transport encryption) → Enable

If your host manages certificates automatically, wait for the status to change to active.

If you are on your own nginx server and already have a certificate, confirm nginx is serving HTTPS with a server block like this:

server {
    listen 443 ssl http2;
    server_name share.yourdomain.com;

    ssl_certificate /etc/ssl/certs/share.yourdomain.com.crt;
    ssl_certificate_key /etc/ssl/private/share.yourdomain.com.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

What you should see when this step succeeds: opening the URL shows a padlock in the browser and starts with https://.

⚠️ If you change web server config on a live site, a typo can cause downtime. Test the config before reloading the server.

Step 4: Add password protection if the result should not be public

If your hosting provider has a password-protection setting, use the dashboard path it provides, commonly:

• Project/Site → Access control → Password protection → Enable

Enter a username and password, for example:

Username: external-review
Password: use-a-long-random-password-here

If you are using nginx, create the password file:

sudo sh -c 'printf "external-review:$(openssl passwd -apr1 "use-a-long-random-password-here")\n" > /etc/nginx/.htpasswd-external-review'

Then add these exact lines inside the location / block for the shared site:

auth_basic "External Review";
auth_basic_user_file /etc/nginx/.htpasswd-external-review;

Test and reload nginx:

sudo nginx -t && sudo systemctl reload nginx

What you should see when this step succeeds: opening the URL in a private/incognito browser window shows a username/password prompt before the page loads.

Step 5: Send the link safely

Send the URL and, if you enabled password protection, send the password in a separate message.

Copy and send this template:

Here is the link to review:
https://share.yourdomain.com

If prompted, use this username:
external-review

Then send the password separately in chat, SMS, or a second email:

Password for the review link: use-a-long-random-password-here

What you should see when this step succeeds: the recipient has the link, and you have not put the password in the same message as the URL.

Verify it works

Check from outside your normal logged-in browser session.

1. Open a private/incognito window.
2. Visit the exact URL you plan to send.
3. Confirm one of these outcomes:
   • For a plain public link: the page opens immediately.
   • For a protected link: the browser prompts for credentials, then the page opens after you enter them.

If you have command-line access, you can also verify with curl:

For a plain public link:

curl -I https://share.yourdomain.com

Expected result:

HTTP/2 200

For a password-protected link, first confirm it blocks anonymous access:

curl -I https://share.yourdomain.com

Expected result:

HTTP/2 401

Then confirm the credentials work:

curl -I -u external-review:use-a-long-random-password-here https://share.yourdomain.com

Expected result:

HTTP/2 200

Common pitfalls

You shared an internal URL instead of a public one

Mistake: sending a link that only works on your office network, VPN, or staging environment.

Symptom: the recipient sees "site can't be reached", a VPN login page, or a timeout.

Fix: send the public https:// URL from your hosting dashboard's Domains/URL section, not the internal preview or company-only address.

DNS record type is wrong

Mistake: creating an A record when your host asked for a CNAME, or the reverse.

Symptom: the custom domain never connects, or it resolves to the wrong server.

Fix: delete the wrong record and recreate the exact record type and value shown by your hosting provider.

DNS has not propagated yet

Mistake: testing the new domain immediately after adding the record.

Symptom: it works for you but not for others, or the host still says the domain is unverified.

Fix: wait 5-30 minutes, then refresh the hosting dashboard and test again in an incognito window.

HTTPS certificate is still provisioning

Mistake: sending the link before TLS/SSL finishes issuing the certificate.

Symptom: the browser shows a certificate warning or loads only over http://.

Fix: wait until the domain status shows HTTPS active, then send only the https:// link.

Password protection was added but nginx was not reloaded

Mistake: editing the config file and stopping there.

Symptom: the page stays public, or nginx serves the old behavior.

Fix: run:

sudo nginx -t && sudo systemctl reload nginx

Browser cache or existing login hides the real result

Mistake: testing in your normal browser session where cookies already exist.

Symptom: you think the link is public or working, but the recipient gets a login prompt or an error.

Fix: test in a private/incognito window before sending the link.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.