Who can open your app
Access settings let you share each part of an app with the people and systems that need it. New Projects start public. When you make one private, Tokay protects its web apps and functions at their existing URLs while letting you keep selected Services or web paths public.
Last updated
AI agent? Start with llms.txt.
The Project's Access tab brings these choices together.
Project access sets the default
A Public Project lets anyone with a Service URL send a request to any web app or function. This is the starting point for a public site, demo, API, or webhook.
A Private Project lets you decide which Services need protection. Restricted Services use the Project's audience, while Services marked Public continue to accept anonymous requests.
Changing the Project back to Public keeps its audience, Service choices, and public paths saved. Those settings take effect again if you make the Project Private later.
Each Service can be Public or Restricted
The Services section shows whether each web app and function is Public or Restricted. Use Edit access when one Service should work differently from the rest of a Private Project.
A Project might contain a restricted dashboard for coworkers and a public function that receives payment events. Both can share the same Config, Secrets, and database without sharing the same public access.
A Restricted Service still has an internet address. Tokay Access checks each request before it reaches the app rather than limiting the Service to a private network.
One audience covers restricted Services
The audience can include Project members, everyone in the Workspace, approved email domains, and individually invited visitors. These rules can be combined to describe the group that should get in.
Every restricted web app and function in the Project uses this audience. Separate Projects are the clearer choice when two parts of an application need different groups of people.
Before saving an audience change, Tokay summarizes who will be able to sign in.
People sign in by email
A visitor who is not signed in enters an email address and receives a magic link. After confirmation, Tokay returns them to the original app.
There is no password or separate Tokay account to create. Sign in covers the Project, so Tokay can use the same browser identity when an admitted visitor opens another restricted Service instead of sending another email link.
The Access tab also lets you add a logo and short message to the sign in page.
Programs use their own credentials
Scripts, CI jobs, and integrations under your control should use a Machine identity and credential. Each caller gets a stable identity with credentials that can be rotated independently.
Connected clients acting for an admitted person can use Tokay Access OAuth. The agent access guide covers that protocol for clients and AI agents.
Public paths keep one web route open
A Restricted web app can expose an exact path or a path subtree for a webhook, callback, or public API without opening the rest of the Service. See Public endpoints for the matching rules and caller checks.
Functions do not use public path rules. Make the whole function Public when an outside provider needs anonymous access, then verify its signature or authentication in your code.
Access changes and activity stay visible
An active Project usually receives an access change in about 10 seconds. An idle Project can take up to five minutes. If Tokay authentication is unavailable, an existing human session can continue until its token expires, which takes no more than 15 minutes.
The access log records invited visitors, successful sign ins, denied requests, Workspace access, and Machine calls. Each row identifies the rule or credential behind the request, which helps you verify a change or investigate unexpected access.