Guide Getting Started

How to give a developer access to your hosting

Give a developer exactly what they need without handing over your own login — here is what a scoped account actually looks like.

iFastHosting Support Team Updated 26 August 2026 6 min read Beginner

Handing your own login to a developer, agency or freelancer is the easiest way to give them access, and also the way that gives away the most — including access to areas they have no reason to touch, and no way for you to tell what changed once several people are using the same credentials. Scoped access solves this properly, and it takes only slightly longer to set up.

Work out what access the job actually needs

Most jobs need one of a small number of things, rarely all of them at once:

File access — to edit a theme, upload a plugin, or work directly with the site's code.
Database access — to make direct changes to the database, separate from files.
DNS access — to configure records for a new service, such as email or a third-party integration.
Full control panel access — occasionally justified for a broader project, but the least common genuine requirement.

Grant the narrowest one that actually covers what they are doing. It is far easier to add more access later if it turns out to be needed than to have granted everything up front and never revisit it.

File access: a scoped FTP account

Rather than sharing your main hosting login, create a separate FTP account limited to a specific folder — the site's root, or a more specific subfolder if the work only touches part of it. The developer gets exactly the file access needed, and nothing outside that folder is reachable from that account at all.

Setting up an FTP account for a developer covers this specific case, and creating an FTP account covers the general steps in your control panel if you have not created one before.

Database access, separately

If the work involves the database directly rather than only through the website's own code, create a database user scoped to that one database rather than sharing broader database credentials. Most control panels let you grant a user access to a specific database only, which keeps the same principle — narrowest access that does the job — consistent across both files and data.

DNS access, without handing over everything else

A developer setting up email authentication, a third-party integration, or a subdomain pointing at an external service usually only needs to add or edit specific DNS records, not manage the whole domain. If your control panel allows separate logins scoped to DNS management, use one rather than sharing full control panel access for what is often a handful of records added once and never touched again.

Billing or account-level access

If the person needs to see invoices, manage services, or open support tickets on your behalf, that is a client area matter rather than a control panel one, and should not be handled by sharing your own login either. Adding a contact to your account covers giving someone their own login with permissions scoped to what they actually need there.

Do not share your own password, even temporarily

A shared password cannot later be revoked from one person without changing it for everyone using it, and it leaves no way to tell whose actions were whose if something goes wrong. A scoped account solves both problems and takes only a few extra minutes to set up.

Full control panel access, if it is genuinely needed

Some projects legitimately need broader access than a single FTP or database account — a full site rebuild, or work spanning several parts of the account at once. Where that is the case, check whether your control panel supports creating a separate, limited administrative login rather than sharing the primary one, so the access can still be identified and removed independently later.

Removing access once the work is done

Treat removing access as part of finishing the job, not an optional afterthought. Delete or disable any FTP account, database user, or contact login created specifically for the project once it is complete, rather than leaving it active indefinitely on the assumption it is harmless. Every additional active login is one more thing that could be compromised later, whether or not it is ever used again.

If you are not sure what to grant

If a developer asks for access and you are not sure what level is appropriate for the described work, ask them directly what they need it for — a reasonable developer can explain in plain terms why they need file access versus database access versus DNS access. If anything about a request still feels broader than the job in front of you, contact support and we can talk through what a sensible scope looks like for the specific work involved.

A short checklist before you hand anything over

Set a unique password on any account created for this purpose, rather than reusing one from elsewhere on your own account.
Keep a note of what was created and why, so that removing it later is a five-minute task rather than a guessing game about which login belonged to which project.
Where the option exists, turn on two-factor authentication on your own primary login, since that is the one account a scoped setup is specifically designed to protect from ever needing to be shared.