Original guide

Cloud hosting deals badge unlimited collaborators. The provider's own permission table refuses 9 of 12 actions

Answer first: Short answer: the two deal pages this site tracks print three distinct access strings between them - the pricing page prints Unlimited collaborators twice inside a generic every-plan feature block and Access sharing per site once, on its Agency plan card, while the cloud hosting page prints Access sharing as a single resource line on its Cloud Startup card - and not one of those strings names a role, a permission, a refusal or a plan gate. The provider's own account-sharing page publishes a two-role permission table with twelve action rows: a Collaborator is allowed three of them and refused nine, an Admin is allowed four and refused eight, and the two roles differ on exactly one row, whether the shared user may buy with the owner's saved payment method. The same documentation states that account sharing grants access to an entire hosting plan, not to a single domain or website, and that the per-website mode is available only on Agency hosting plans - which is the plan line the cloud card is not on. Three provider pages publish three different refusal lists and no two of them match; read together they name ten distinct refusals. Two-factor authentication, the words password, permission and login, the backup codes, the login history and the account-recovery path appear zero times on both deal pages, yet the provider documents all of them, including a recovery request answered within two business days.

Published: 2026-10-14 00:10

What this guide adds

Every provider fact in this article comes from pages the provider publishes and this site read: the two deal pages this site tracks and the eight knowledge-base articles listed below. The occurrence counts and the exact card strings are this site's own reading of those two deal pages, flattened and lowercased before counting. The arithmetic is this site's own calculation on numbers the provider prints, and it is derived rather than sourced: nine refusals out of twelve table rows is 75%, eight out of twelve is 66.7%, and the one row that separates Admin from Collaborator is 8.3% of the table. The count of ten distinct refusals is this site's own union of three lists the provider publishes separately, not a list the provider prints anywhere. The four-file ceiling on the recovery upload is derived from the provider's own 2 MB per-file and 8 MB multi-file caps. Where the provider publishes nothing, this article says unstated rather than estimating: no shared-user count cap, no per-user activity attribution, no requirement that a shared user enable two-factor authentication, no invitation expiry, no stated revocation latency and no version date on the permission table are published on any page this site could read. No blocked source was fetched and no blocked source is quoted: the benchmark domain recorded in the older gap entries serves a challenge on every path, including its robots file, and Reddit stays blocked.

What the two deal pages actually print about access

Flattened and lowercased, the pricing page prints four occurrences of access-sharing text and the cloud hosting page prints one. The pricing page carries Unlimited collaborators twice inside a generic block headed Every plan has everything you need and more, and it carries Access sharing per site once, on its Agency plan card, tagged NEW. The cloud hosting page prints Access sharing as a single resource line on its Cloud Startup card, sitting between Unlimited websites and the plan price, with no per-site qualifier and no price of its own.

The cloud page also prints invite your team to collaborate on projects inside a FAQ answer about agencies using hPanel, and collaborate on exciting projects in a dashboard blurb. Neither line is attached to a plan card, and neither describes what a collaborator may do.

The words that would let a buyer judge the feature are absent from both pages. Counted the same way, two-factor, 2fa, two-step, password, permission, login, account sharing, backup code, recovery email, login history, account activity, impersonate, role, admin, owner and grant each score zero on the pricing page and zero on the cloud hosting page. The pricing page does print log in once, as a verb, in a free-domain FAQ answer about logging in to the dashboard.

That is the whole of the published access vocabulary across the two pages: three distinct strings - Access sharing per site, Unlimited collaborators and Access sharing - in four occurrences, and not one of them names a role, a permission, a refusal, a second factor or a recovery path.

The provider's own permission table has twelve rows, and a Collaborator is refused nine

The knowledge-base article How to share access to your account at Hostinger publishes a role table under the heading What roles are available for a shared user? Two roles are named, Collaborator and Admin, and the table carries twelve action rows, each marked Allowed or Not allowed for each role.

A Collaborator is allowed three of the twelve: manage website files, add subdomains, and edit DNS if the domain is included in the shared access. The other nine rows are marked Not allowed: purchase using the owner's saved payment method; add or manage payment methods; change account email, password, or profile info; invite other users to the account; transfer, unlock, or edit domain contact info; set up a new hosting, VPS, or email plan; claim a free domain or free email; delete the account; and create or set up email accounts.

Read against the table itself, that is nine refusals out of twelve rows, or 75%. That figure is this site's arithmetic on the provider's own counts rather than a percentage the provider prints.

The table's notes widen one of those rows. Domain restrictions also cover managing auto-renewals, selling domains in the aftermarket, responding to a domain buying service, and managing backorders. A separate note states that creating shared access to a free email plan is not possible and that it is available only for paid email plans. The section closes with the reason a shared user sees a different panel: due to these restrictions, the panel for a shared user shows fewer options than the owner account.

Admin is one permission wider, not a different role

An Admin is allowed four of the twelve rows - the same three a Collaborator gets, plus purchase using the owner's saved payment method. Everything else on the table is refused to both roles, including adding or managing payment methods, changing the account email, password or profile information, inviting other users, transferring or unlocking a domain, setting up a new hosting, VPS or email plan, claiming a free domain or free email, deleting the account, and creating or setting up email accounts.

The distance between the two roles is therefore one row out of twelve, or 8.3% - again this site's arithmetic on the provider's table, not a published figure. The second sharing article, How to get shared access to another account, describes the same split in prose: a Collaborator can modify files and websites, manage VPS if any, and change other hosting-related settings, while an Admin, in addition, can purchase new hosting plans or domains with an already added payment method.

Two consequences follow from the table and appear on no plan card. First, no role can touch the money: neither Collaborator nor Admin may add or manage a payment method, and only Admin may spend one the owner already saved. Second, no role can touch the identity: changing the account email, password or profile information is refused to both, which means a shared user cannot lock the owner out of their own account, and equally cannot repair it.

Three provider pages publish three different refusal lists

The provider publishes the refusal list more than once, and the lists do not agree. The article What actions can the user with Granted Access perform on the account lists seven refusals as bullets, and one of them is Change the main domain - a line that appears in neither of the other two lists.

The longer sharing article lists eight refusals. It drops Change the main domain and adds two lines the seven-bullet list does not carry: Set up new hosting or email plans, and Claim a free domain and a free email. The request-access article adds a third variant, whose not-allowed list includes Add websites, a line that appears on neither of the other two.

Read together, the three published lists name ten distinct refusals, and no single list names all ten. The provider does not reconcile them, and none of the three carries a date against the permission table it sits beside.

The Add websites line also sits next to a table row that reads Add subdomains - Allowed for both roles. This site reports both as printed: adding a subdomain is allowed, adding a website is refused, and neither page explains where the boundary between the two falls.

Account sharing is all-or-nothing across a hosting plan

The feature the cloud plan card badges is scoped by a rule the card does not print. The sharing article's FAQ answers the question Why can't I share access to only one domain or website? with the rule itself: Account Sharing grants access to an entire hosting plan, not to a single domain or website, and sharing a hosting plan gives the other user access to all websites under that plan.

The companion article states the same scope positively: account sharing applies to all websites on a web or cloud hosting plan. A shared user with hosting access can manage website files, subdomains and hosting settings, and the grant is assembled service by service, with the owner choosing which services to share and at which access level.

This is why Unlimited collaborators reads differently once the scope is known. The badge counts people; the rule fixes the unit those people are granted. One shared user receives the whole plan, and the deal pages print no mechanism for narrowing that to a single site on the plans they price.

The per-site mode the Agency card badges is the Agency-only one

The pricing page prints Access sharing per site once, on the Agency plan card, tagged NEW. The cloud hosting page prints Access sharing once, on the Cloud Startup card, with no per-site qualifier. The provider's own documentation treats those as two different capabilities and says only one of them can be scoped to a single website.

The sharing overview names the scoped mode and its plan gate in one line: Website collaborators - share access to a single website (Agency hosting only). The step-by-step section repeats the gate: this option is available only on Agency hosting plans and allows you to grant access to a single website without sharing the entire hosting plan. The FAQ puts the choice plainly - to limit access to one specific website, create a separate FTP account for that website, or upgrade to an Agency plan, which supports per-website access sharing.

The cloud hosting page does sell the Agency route, but as a separate sentence inside a FAQ answer: cloud hosting plans are among those we offer in our agency hosting services. What the Cloud Startup card's Access sharing line therefore points at is the whole-plan mode, the one the same provider says cannot be narrowed to a single site.

Sharing a domain shares DNS only, and Ecommerce is excluded

Account sharing is not the only way access leaves an account, and the alternatives carry their own boundaries. A shared domain service is narrower than its name suggests: the sharing article states that a shared domain includes DNS management but not the website, and the FAQ repeats it - domain access allows DNS management only, and email access allows managing the email plan only.

The fallback route is documented as the workaround for exactly that limit. A hosting plan is set up with a default FTP account that reaches every domain and file on the plan; to narrow it, the provider documents creating an additional FTP account and assigning it to a directory, with the example path /home/u123456789/domains/domain.tld/public_html. On web, cloud and Agency hosting each database has a single database user, so sharing database access means handing over the existing credentials and the phpMyAdmin link rather than creating a separate user. FTP and MySQL access is not available for websites created with Hostinger AI Builder.

One product is excluded from sharing altogether. The sharing article states that Account Sharing does not currently support sharing access to Hostinger Ecommerce stores, and that the store owner must manage the store directly from their own account.

Two steps of the mechanism are also published and printed on no deal page. A grant is completed by email: a confirmation email goes to the invited user, who must click the link, and a user who has no Hostinger account yet is prompted to create one. The same article notes that delivery can take up to 15 minutes. On a VPS the documented route is different again - a separate SSH user created on the server, with adduser followed by usermod -aG sudo, so that a developer can work in a terminal without a dashboard account at all.

The account-security layer no deal page prints

The two deal pages print no account-security vocabulary at all, but the provider documents a full layer for it. Two-factor authentication is offered in two forms, application and email, and only one may be active at a time; the application method is described as highly recommended and is set up by scanning a QR code with an authenticator app such as Authy or NordPass. Backup codes are shown once. If they are not saved, the provider's instruction is to reset them by setting up two-factor authentication again, and a lost two-factor device is handled by contacting support rather than by a self-service path. Disabling is documented too, using either the original method or a backup code.

Two conditional routes matter because they are the recovery path of last resort. With a verified backup email on the account, the verification code can be sent there during the standard login flow, not only during suspicious login events. With a verified recovery email, the code can be sent there during what the article calls the Suspicious Login - Risky 2FA flow, when additional verification is required and the primary email cannot deliver the code.

Login history is published as a self-service check. The Account Activity page shows the date and time, device, location, IP and login method of previous logins, and a Don't recognize a device? button logs the user off every device and changes the password in one step. The same article notes that a particular hosting plan keeps its own activity log, separate from the profile-level view.

Account recovery is documented as a document-verified process with a published clock. A payment receipt is mandatory; a government-issued ID, a photo of the credit or debit card showing the first six and last four digits, or a business registration are accepted alongside it. Screenshots are explicitly refused - SMS screenshots, email screenshots including the provider's own emails, dashboard screenshots, and invoices or invoice screenshots. Virtual card images are accepted only with a full bank statement. Files must be JPG, PNG or PDF, capped at 2 MB each and 8 MB in total for multiple files, and the request is answered at the alternative email address within two business days. The provider also recommends setting a recovery email before it is needed, from Profile, Account Information, Account Settings, Recovery email.

One feature, three names in the provider's own documentation

The provider calls the sharing feature three different things across the pages this site read. Account Sharing is the name used in the sharing overview, the share-access article, the request-access article and the granted-access article. The hacked-account article recommends a different name in a single line: if you wish for a developer to manage your website, you can use our Access Manager feature. The share-access article uses a third name in its closing notes, referring to the Access Management feature and to the Change permissions option in the Access Management tab.

All three names attach to the same dashboard capability, the one whose permission table is quoted above; the other documented sharing routes, website collaborators and FTP or MySQL accounts, are named separately and consistently. A buyer looking in the dashboard for the feature a deal page badges as Access sharing is looking for whichever of the three names their account happens to show.

One address is worth recording for the same reason. The knowledge-base URL whose slug reads how-to-create-multiple-logins-to-your-account-at-hostinger-for-friends-or-customers now renders as How to share access to websites in Hostinger, an overview of the three sharing routes. The provider publishes no page stating a numeric cap on how many users may be granted access, which is consistent with the deal page's Unlimited collaborators string without being the same claim.

What the access badges leave unstated

Several cells a buyer would want are not published on any page this site could read. The number of shared users a plan accepts is unstated: the deal page says unlimited and the documentation prints no figure to check it against. Per-user activity attribution is unstated: the published activity views are per profile and per hosting plan, and neither is described as filtering by shared user. Whether a shared user can be required to use two-factor authentication is unstated. Whether an invitation expires is unstated, since the documentation gives the 15-minute delivery window and the ability to resend a grant, and stops there. How quickly a revocation takes effect on a session already open is unstated; the documented step is removing access from the grant list. And the permission table carries no version date, so which rows applied on the day a given plan was sold is unstated.

What is stated is enough to price the badge honestly. The pricing page prints Unlimited collaborators and Access sharing per site; the cloud page prints Access sharing. The provider's own table allows three of twelve actions to a Collaborator and four to an Admin, refuses nine and eight respectively, and scopes the whole arrangement to one hosting plan at a time, with the per-website version reserved for a plan line the cloud card is not on. The money and the identity stay with the owner in both roles. And the second factor, the backup codes, the login history and the two-business-day recovery path that decide whether the owner keeps the account at all are published in the knowledge base and printed on neither page.