Ask for provider and role
Start with the hosting provider, control panel URL, and whether the client can invite a collaborator. If not, ask how they prefer to share temporary access.
Request backup details
Before work begins, confirm backup frequency, restore process, staging availability, and who approves deployment.
Capture technical constraints
Ask about PHP or Node versions, caching, CDN, SSL, email records, redirects, cron jobs, and any previous hosting problems.
Use a portal
Hosting details are easy to lose in email. Kicklayer keeps them with the rest of the onboarding request and makes missing launch details visible.
Plain-language access request
Use this as the human version of the ask before you turn it into a structured portal.
Hosting access should include the access type, environment, backup process, database or SFTP needs, and boundaries for production changes.
Fields worth separating
Separate fields help the client understand what you need and help your team see exactly what is still missing.
Registrar
Required access
Identify where the domain is registered and who can approve DNS changes.
Hosting
Required access
Request hosting panel, SFTP, database, staging, or collaborator access as needed.
DNS records
Required text
Collect important records for website, email, verification, CDN, and redirects.
Backups
Required text
Ask how backups work, where they are stored, and who can restore them.
Launch approval
Required approval
Name the person authorized to approve DNS, SSL, CDN, and go-live changes.
Safe access checklist
Use these checks before asking a client to grant access or share sensitive account details.
Domain
Confirm registrar, domain owner, and DNS manager.
Registrar, DNS, and hosting may be three different services.
Hosting
Share hosting panel, SFTP, database, staging, and backup details.
Launch and troubleshooting often need more than CMS access.
Identify email records and services that must not be disrupted.
DNS mistakes can break client email.
Security
Confirm SSL, CDN, firewall, and access restrictions.
Security layers can block deployment or verification.
Launch
Set launch window, rollback plan, and approval owner.
DNS changes should have timing and accountability.
Access request wording
The right wording protects the client relationship and reduces back-and-forth.
Do
- Ask who owns DNS before requesting changes.
- Document email-related records before launch work.
- Confirm backups and rollback process.
- Separate registrar access from hosting access.
Avoid
- Assume the hosting provider controls DNS.
- Change records without knowing email dependencies.
- Request shared owner passwords when collaborator access exists.
- Launch without a named approver and rollback path.
Why move access requests into a portal?
The same request becomes more reliable when every field has an owner, a status, and a place to submit it.
Domain, hosting, DNS, backup, and launch approval requests stay connected.
Clients can see which access details are still missing before go-live.
Your team has one place to review launch-critical infrastructure details.
Practical questions
What is the difference between domain and hosting access?
Domain access controls registration and often DNS. Hosting access controls website files, database, backups, and server settings. They may be separate accounts.
Should I ask for DNS records?
Yes, especially before launch or migration. Email, verification, CDN, and app records can be easy to break accidentally.
What should be confirmed before launch?
Confirm DNS owner, hosting access, backups, SSL, CDN, email records, launch window, rollback process, and final approval owner.