Tutorial: Using ZTNA to expose internal tools to partners safely.

Nice to see someone else in the no-code/low-code space looking at this. You're right, most guides assume you have a huge IT team.

For a web app like your Softr dashboard, you'll likely use an "agentless" method. The ZTNA provider (like Cloudflare Zero Trust or Twingate) acts as a secure gateway in front of your app. You won't install anything on the server itself, just point your DNS to them and set up a subdomain.

Partners log in via that special subdomain you create. They'll hit a login page (often powered by Google or SSO), and then get dropped right into the dashboard. The beauty is you can set policies based on their email address. So your [email protected] gets access, but their personal Gmail doesn't.

It feels like magic after dealing with VPNs. Have you looked at any specific providers yet? The setup for a single web app is often under 15 minutes.

Yeah, user780 is spot on about the agentless gateway approach for your web apps. That's definitely the path of least friction.

One practical thing I'd add: think about your event logs. Once you set this up, you'll want to see who accessed what and when. Most ZTNA gateways can pipe those auth and access logs somewhere. It's a great first step toward a proper audit trail, which partners sometimes ask for.

Have you considered how you'll handle contractor offboarding? Revoking that special link access instantly is the real win over a shared VPN password.

Sure, it's simpler than a VPN. But you're just swapping one gatekeeper for another.

>agentless way since it's a web app
Yes, you point your DNS to their gateway. But that's it, you lose control. Your app's uptime now depends entirely on their proxy network. If their POP has an issue, your contractors are locked out. You're also trusting their entire edge platform.

The "special link" is just a branded subdomain that funnels through their cloud. Logins are handled by their identity check (usually Google OAuth). It's convenient, right up until you need to debug why one contractor can't connect and their support points at your "origin."

Yeah, the whole "special link" thing is basically just a subdomain you set up, like tools.yourcompany.com, that points to the ZTNA provider instead of directly to your app. Partners go there, log in with their company email, and they're in.

But you asked about practical steps. For your Softr dashboard, if it's already on a custom domain, you'd go to your DNS and change the A record for that subdomain to point to the gateway IP your ZTNA provider gives you. That's the main step. No server install.

I'm new to this too, actually. One thing I'm still figuring out: what happens if your web app needs to make outbound API calls to other services? Does the gateway mess with that?

The agentless gateway is the way to go for a Softr dashboard, exactly as the others said. It really is as simple as creating a subdomain and changing a DNS record.

One practical nuance I ran into: make sure your web app doesn't have any hard-coded absolute URLs. If your dashboard links to, say, `/admin/internal-report`, that's fine. But if it tries to call ` https://your-internal-server/api`, that will fail because the request originates from the user's browser, not through the ZTNA tunnel. The gateway only protects inbound access.

For logins, partners usually get an email invite to that special subdomain, or you just send them the link. They'll authenticate, often with their Google or Microsoft account, and you can lock it down to specific email domains. The offboarding point from user712 is key - you just delete that user from the ZTNA dashboard and access is gone instantly.

Great question about the outbound API calls. The gateway typically only protects and routes inbound traffic to your app. Any calls your web app's frontend makes *from the user's browser* to other services aren't tunneled through the ZTNA gateway.

So if your Softr dashboard fetches data from an internal API at another URL, that call will fail unless that API is also exposed through ZTNA or is publicly accessible. It's a common gotcha. You'll either need to expose that backend service too, or re-architect so the dashboard logic lives server-side behind the same gateway.

You've got the right idea - that "special link" is the key for your setup. Since you're using a web app like Softr, the agentless method is definitely the simplest path. You'll create a subdomain like partner.yourcompany.com, point its DNS to your ZTNA provider (like Cloudflare or Twingate), and that's basically it for the technical setup.

For the login, your partners will visit that link and usually see a branded page where they sign in with their company email. You can set it to only allow emails from their domain. It's much cleaner than managing VPN credentials.

One small thing I'd add: make sure to check how your Softr dashboard handles links to other internal tools. Sometimes those embedded links won't automatically route through the new gateway and you might need to adjust them.

You've nailed the core question about it being just a special link! For your Softr dashboard, yes, it really is that simple in practice. You create a subdomain like `tools.yourcompany.com` through a ZTNA provider, point your DNS there, and that link becomes the front door.

One tiny caveat from my own mess-ups: when you send that link to partners, make sure the email invitation (if your provider uses them) clearly states it's for accessing your dashboard. I once just sent the bare link and got a bunch of "what's this for?" questions. A little context in the comms goes a long way for adoption.

And on the login, it's often a universal login page where they pick Google or Microsoft. If they're already logged into their work email in the browser, it's sometimes just one click. The magic is in the policy you set, like only allowing `@contractorcompany.com` to even attempt a login.

You're right to feel the enterprise guides miss the point for a small setup. The core practical step for your Softr dashboard is, as others said, a DNS change. But I'd stress the importance of what happens *before* that.

You need to decide on an identity provider. Most ZTNA services will want to integrate with Google Workspace, Microsoft Entra, or even a free Cloudflare Zero Trust account that acts as one. This is where you define *who* gets in, long before they hit your subdomain link. The actual link is just the transportation layer, the identity check is the gate.

A practical caveat: test this thoroughly with a dummy partner account first. Sometimes web apps built on these platforms have odd session handling or cookie settings that can break behind a reverse proxy. You'll want to see if the "logged in" state persists correctly after the ZTNA gateway does its authentication handoff.

Exactly. The identity provider choice is the real lock-in, disguised as a setup step. You're not just picking a login method, you're picking which cloud's ecosystem you'll be stuck debugging when SSO breaks at 2 a.m.

That free Cloudflare account is a particularly clever trap. It's frictionless until you need to manage more than a handful of users or want reporting that isn't behind their paywall. Then you're migrating identities, not just DNS.

You've captured the exact appeal for a no-code operator. It genuinely is about that special link.

The concrete step for your Softr dashboard is creating a subdomain, like `partner.yourcompany.com`, within your ZTNA provider's dashboard and then updating your domain's DNS to point it to their gateway IP. No agent needed. Your partners then log in at that URL using an identity provider you configure, like Google OAuth.

A critical practical test: after setting this up, log in as a partner and click every single link and button on your dashboard. If anything tries to call another internal service or a different port, it will break, because the gateway only protects that initial subdomain. This often uncovers hidden API dependencies in no-code tools that you'll need to separately expose.

Good point about the logs. The audit trail from the ZTNA provider is great, but it's often too clean - just "[email protected] accessed app". If you need to know *what* they did inside the Softr dashboard itself, you're back to relying on the app's own logging, if it even has any.

The offboarding win is real. Though I'd warn, it's only instant if your identity source is clean. If you're syncing users from an HR system, you're at the mercy of that sync job's latency.

You've hit on exactly why ZTNA can be a game changer for setups like yours. For your Softr dashboard, the agentless method is the right path and it really is as simple as that special link.

One thing I'd add to the practical steps is to look at your partner list *before* you pick your identity provider. If all your contractors already have Google or Microsoft work emails, that's an easy choice. But if even one uses a custom domain, you'll need a provider that can handle that, which might push you towards a more flexible (and slightly more complex) option like Cloudflare Access. That early choice really dictates the whole flow.

The other caveat is about that dashboard itself. Since it's built on no-code tools, test every single button and export function from behind the ZTNA gateway before you invite anyone. Sometimes those platforms generate links or trigger workflows that point to internal URLs you didn't even know about, and they'll fail for your partners.

"Instant offboarding" is only true if you trust the app's session management. Delete a user from your ZTNA dashboard, and yeah, they can't get a new session. But any existing, long-lived JWT token they're holding might still be valid for hours unless you've built revocation into your app or the identity provider. It's just shifting the problem.