Server-side authorization
Protected actions must verify identity, workspace membership, role, scope, resource access, and subscription state where relevant.
Resource · SecuritySecurity Trust Center
Security built for Git-backed publishing workflows.
Acrosite is designed around workspace isolation, server-side authorization, scoped GitHub App access, protected deployment triggers, Client Reviewer isolation, and safe logs that never expose secrets.
Workspace isolationGitHub AppClient Reviewer isolationNo secrets in logsServer-side checks
Security principles
Security starts with boundaries, roles, and server-side checks.
A small set of consistent rules sits underneath every surface — not a list of badges, but the behaviour Acrosite is designed around.
Workspace isolation
Workspace data is treated as the main tenant boundary, with client, project, content, media, review, and log records scoped accordingly.
Least privilege
Users and integrations should receive only the access needed for their role or task — nothing broader by default.
Secrets stay server-side
GitHub tokens, deployment hook URLs, webhook secrets, service keys, and provider credentials must not reach the browser.
Client Reviewers are isolated
Client Reviewers only access assigned projects and assigned review content through the dedicated client portal.
Logs are useful but sanitized
Publish Logs and Deployment Logs should explain what happened without exposing secrets, stack traces, raw provider payloads, or hook URLs.
Access boundaries
Different surfaces. Different protections.
Acrosite is not one undifferentiated app. Each surface sits on its own boundary with its own checks — and the client portal is deliberately separate from the customer app.
Access boundary mapacrosite.com · 6 surfaces
AcrositeServer-side authorization gate
Public Website
//features/pricing/security
Public, no customer data.
Customer App
/app/*
Auth, workspace membership, role, scope, subscription state.
Client Portal
/client/client/overview/client/reviews
Authenticated Client Reviewer, assigned projects, assigned review content only.
Internal Admin
/acro-admin
Acrosite Super Admin only. Audited internal operations.
API / Webhooks
/api/*/api/webhooks/*
Auth, authorization, provider verification, worker secrets where required.
Background Workers
worker routes
Worker secret required, idempotent, logged, no public access.
/client is a separate surface from /app. Client Reviewers authenticate into the client portal and never inherit customer app access.
Tenant isolation
Workspace data stays inside its workspace boundary.
Acrosite is designed around workspace-scoped data so one workspace cannot access another workspace's clients, projects, content, media, reviews, publishing jobs, logs, or billing state.
Workspace A
acmeagency
- Clients
- Projects
- Content
- Media
- Review Requests
- Publish Logs
- Deployment Logs
- Team Members
Scoped to this workspace
Workspace B
othersite
- Separate clients
- Separate projects
- Separate content
- Separate media
- Separate logs
- Separate billing state
Scoped to this workspace
No cross-workspace access. This describes Acrosite's product architecture and security design — not a formal certification claim.
Role-aware access
Access depends on role, scope, and resource.
Acrosite permissions are designed around who the user is, where they belong, and what resource they are trying to access — not a single global on/off switch.
Broad workspace management and publishing control.
Content workflow, approvals, scheduling, publishing, and scoped logs where allowed.
GitHub, deployment trigger, paths, integrations, and technical troubleshooting.
Content creation and editing within assigned or permitted scope.
Read-only visibility where allowed.
Assigned project and assigned content review only. No internal workspace access.
Internal platform support / admin role, separate from customer workspace roles.
Role
Workspace settings
Content & publishing
GitHub & deployment
Logs & audit
Client review portal
Owner / Admin
Manager
scoped
scoped
Developer
scoped
scoped
scoped
Editor / Author
scoped
Viewer
scoped
Client Reviewer
Super Admin/acro-admin
Full accessScope-aware (assigned / permitted only)No access
Client Reviewer isolation
Client Reviewers get review access, not workspace access.
Client Reviewers use the dedicated client portal. They can see assigned projects and assigned review work without accessing GitHub, deployment settings, billing, team management, unrelated projects, or internal workspace operations.
Client Reviewer
Client portal · assigned onlyAuthenticated
Client portal · assigned onlyAuthenticated
acme-projectNeeds Review
main-siteReviewed
Hidden — not part of the client portalGitHubDeploymentBillingTeamWorkspace settingsOther projects
Client Reviewer can see
- Assigned projects
- Needs Review
- Changes Requested
- Reviewed
- Published items where involved
- Review comments
- Approve / Request Changes
Client Reviewer cannot see
- GitHub settings
- Deployment trigger profiles
- Billing
- Team Members
- Internal workspace settings
- Other clients
- Other projects
- Publish Logs (unless allowed later)
GitHub security
Repository access is scoped through a GitHub App.
Acrosite is designed to connect through a GitHub App so repository access can be scoped to selected repositories and managed through GitHub installation settings.
Acrosite GitHub App
acmeagency · client-site
acmeagency · client-site
- GitHub App connection (not personal access tokens)
- Repository access scoped to selected repositories
- Repository and branch verification
- Contents permission for publishing
- Short-lived installation tokens
- Tokens never reach the browser
- Installation can be revoked from GitHub
Access is scoped and revocable. The connection is managed through GitHub App installation settings — Acrosite should never expose tokens or private keys to the browser.
InstallationConnected
Repositoryclient-site
Branchmain
PermissionContents read/write
AccessScoped
TokenServer-side only
StatusVerified
Deployment trigger security
Deployment trigger secrets stay protected.
Deployment trigger URLs and provider credentials should be stored and used server-side. Normal users should see safe status and masked metadata — not raw hook URLs or secrets.
VercelManualMore Coming Soon
ProviderProvider-neutral profile
StatusConnected
Hook URL••••••••abcd
Last tested2 minutes ago
Trigger resultAccepted
SecretServer-side only
Safe to show
- Connection status
- Masked hook metadata
- Test trigger status
- Last tested timestamp
- Provider trigger result
- Safe error summary
Safe observability
Logs should help recovery without leaking secrets.
Publish Logs, Deployment Logs, Activity, and Audit Logs should help teams understand what happened while keeping secrets, raw payloads, and internal stack traces out of normal UI.
Sanitized
Publish Logs
- Commit status
- Commit SHA
- Generated file path
- Deployment trigger result
- Safe failure reason
Sanitized
Deployment Logs
- Trigger type
- Provider
- Safe request/response summary
- Status
- Timestamp
Sanitized
Activity / Audit Logs
- Access events
- Content events
- Publishing events
- Billing events
- Admin events
Not logged or shown in normal UI
Sensitive values are kept out of Publish Logs, Deployment Logs, Activity, and Audit Logs.
GitHub tokensDeployment hook URLsWebhook secretsPayment provider secretsEmail provider secretsRaw payloadsStack tracesEnvironment variablesCookiesSession data
Webhooks and workers
External events and background jobs require verification.
Acrosite's background operations are designed to avoid public, unauthenticated execution. Webhooks should be verified, and worker routes should require internal secrets.
Verified webhooks
Provider webhooks must be verified before processing.
Signature verified
Publishing workers
Scheduled publishing workers require worker authentication and re-check permissions, subscription state, and project configuration.
Worker secret required
Retry workers
Retry actions should be idempotent, bounded, logged, and scoped to the right resource.
Idempotent & bounded
Retention / cleanup workers
Cleanup workers should run with protected access and sanitized results.
Protected access
Internal admin boundary
Workspace Owners are not Acrosite Super Admins.
The internal /acro-admin area is separate from customer workspaces. Workspace ownership does not grant internal platform admin access.
Customer Workspace Owner
Customer role
- Manages own workspace
- Billing for own workspace
- Team for own workspace
- Projects and content for own workspace
Acrosite Super Admin
Internal platform role
- Internal platform support / admin role
- Access to the internal admin area
- Platform monitoring and support tools
- Audited internal actions
Customer roles do not automatically become platform roles. Internal admin access is granted separately.
Clear boundaries
What security means in Acrosite.
Confident and specific about what the platform is designed to do — and honest about what it does not claim to be.
Acrosite security is
- Workspace isolation
- Server-side authorization
- Role and scope checks
- Client Reviewer isolation
- Scoped GitHub App access
- Server-side secrets
- Verified webhooks
- Worker protection
- Sanitized logs
- Audited important actions
Acrosite security is not
- A substitute for your own website security
- A guarantee that your repository is risk-free
- A promise of full provider deployment lifecycle tracking
- A place to expose raw tokens or hook URLs
- A compliance certification claim
- A reason to give clients GitHub access
- A replacement for legal / security review before enterprise procurement
Security FAQ
Questions about how Acrosite protects your work.
Access, GitHub, deployment secrets, logs, client isolation, and the internal admin boundary — the specifics teams ask before trusting a publishing platform.
Contact UsNo. Client Reviewers use the dedicated client portal and only see assigned projects and assigned review content. GitHub, deployment settings, billing, Team Members, and internal workspace areas remain hidden.
Acrosite is designed around a GitHub App connection so repository access can be scoped to selected repositories and managed through GitHub installation settings.
No. GitHub App private keys and installation tokens should remain server-side and should never be exposed to the browser.
Raw deployment hook URLs should not be exposed in normal UI. Users should see masked metadata, connection status, test status, and trigger results.
No. Publish Logs, Deployment Logs, Activity, and Audit Logs should avoid exposing tokens, hook URLs, raw provider payloads, stack traces, cookies, session data, environment variables, or secrets.
Workspace is the main tenant boundary. Protected actions should verify user identity, workspace membership, role, scope, and resource access server-side.
No. Client Reviewers should only see assigned projects and assigned review content through the client portal.
Only separately authorized Acrosite Super Admins. Workspace Owners do not automatically get internal admin access.
Acrosite's security page describes product security design and access boundaries rather than certification claims. Any formal certification would be stated only once it is actually completed.
Contact Acrosite support with the issue details. Please do not include secrets, tokens, passwords, or private customer data in the initial report.
Start here
Protect your Git-backed publishing workflow.
Registration is coming soon. Contact us to talk through your publishing workflow, or read the docs to see how Acrosite works.
Registration opening soonGitHub AppClient isolationServer-side secretsSafe logs