Security and shared responsibility

synsmarts secures and operates the managed hosting platform. Customers remain responsible for the identities, code, data, integrations, and configuration they control.

Managed hosting changes where controls run; it doesn’t transfer ownership of your business data, application behavior, or access decisions to synsmarts.

Responsibility by area

Area	synsmarts manages	Your Team manages
Platform	Service infrastructure, tenant isolation, supported runtime delivery, platform patching, monitoring, and platform incident response	Supported App configuration, application behavior, business continuity requirements, and verification that the App works for its users
Accounts and Team access	Authentication, session controls, Team-scoped authorization, role enforcement, and audit events	Unique sign-in credentials, optional 2FA enrollment, recovery-code custody, session review, least-privilege roles, and prompt removal of access
Code sources and releases	GitHub App integration without a customer personal access token, managed Workspace access, validated release workflows, and release history	GitHub organization and repository access, installation scope, branch protections, Workspace access and change review, dependency safety, and deliberate selection of the source to release
App code and data	Managed runtime boundaries, supported service configuration, and platform backup mechanisms	Code, plugins, packages, framework compatibility, App users and permissions, data classification, lawful processing, and data retention requirements
Vars and secrets	Write-only secret values, validated secret references, scoped runtime delivery, and managed application of configuration	Choosing the correct value class and runtime targets, rotating credentials at their issuer, removing old credentials, and keeping secret values out of code and plain-text Vars
Domains and traffic	Supported routing, certificate workflows, maintenance controls, WAF enforcement, and customer-visible WAF events	Domain ownership, registrar and external DNS changes, maintenance decisions, WAF mode and protection level, geographic policy, narrow exclusions, and testing legitimate traffic after changes
SSH and database access	Tenant-scoped SSH authentication, source-IP enforcement, audit records, and scoped file-transfer and database channels	SSH users, keys, source ranges, per-user grants, database privileges, password custody, and immediate revocation when a person, device, or network no longer needs access
Backup and recovery	Creation and reporting of supported recovery points, retention enforcement, safety backups, and managed restore workflows	Selecting the correct recovery point or media version, understanding the data impact, deciding when recovery is appropriate, and verifying restored business data and integrations

Use Team roles and permissions when assigning access. Owners and admins should review membership after staffing changes, grant the least role required, and remove access rather than relying on an informal agreement that a former user won’t sign in.

Security-sensitive changes need verification

A portal action reaching a successful state proves that the managed workflow finished. It doesn’t prove that the selected input was safe or that the resulting business behavior is correct.

Examples:

• a completed deploy doesn’t prove that the released code or dependency set is secure;
• an applied secret change doesn’t prove that the external credential works or that the old credential was revoked;
• an active domain and certificate don’t prove that every redirect, webhook, payment callback, or email record is correct;
• a completed restore doesn’t prove that record counts, recent writes, media links, or external integrations are correct; and
• an investigation with no findings isn’t an all-clear security attestation.

After an account, access, repository, secret, DNS, WAF, SSH, deploy, restore, or configuration change:

1. Confirm the portal shows the intended current state, not only a submitted request or an old report.
2. Test the exact path the change was meant to affect.
3. Test one adjacent security-sensitive path, such as sign-in after an account change or checkout after a domain or restore change.
4. Confirm removed access, keys, sessions, credentials, or network ranges no longer work.
5. Record the operation identifier and time when the change is part of an incident or controlled maintenance.

Follow the specific procedures for account security, Team members, repository access, Vars and secrets, domains, WAF policy, SSH access, and backups.

Respond to a suspected compromise

Contain access through the narrowest control you own. Don’t wait for support to revoke customer-controlled access.

• Account or Team access: change the affected sign-in method, revoke unrecognized sessions, remove unknown members, and review Team Activity.
• Exposed credential: revoke or rotate it at the issuer first. Replace the runtime or build secret in synsmarts; use Apply now for a runtime secret so running containers stop using the previous value. A build-secret replacement takes effect only in the next image build.
• Repository access: remove unexpected repository access in GitHub, review recent code and releases, and prevent another release until the source is trusted.
• SSH access: disable the affected user, remove the key or source range, and verify that a new connection is rejected. Existing sessions and database forwards terminate within the revocation interval; contact support if one remains active after the change finishes applying.
• Active App impact: preserve identifiers and timestamps, use maintenance mode only when it safely contains traffic, and follow the App incident procedure.

Open a Critical support request for suspected unauthorized access, active customer impact, or possible data loss. Include the affected App, observed impact, start time, recent changes, and safe operation identifiers. Never include passwords, private keys, authenticator or recovery codes, API tokens, secret values, payment-card data, or unredacted customer records.