Recover GitHub and Hosting Access When a Freelancer Owns It

What you are dealing with, in plain terms

If a freelancer set up your code and hosting under their own email, you don’t actually control the systems that run your product. You might have the app files on your laptop, but the real control points are the accounts: your repo host (like GitHub), domain registrar, hosting or cloud provider, email, and any third-party tools.

This happens for normal reasons. A contractor moves fast, uses the email already logged in on their computer, and creates everything as the first admin. If nobody pauses to add you as an owner, your product ends up dependent on one person’s inbox, password manager, and two-factor authentication (2FA). It’s often not malicious. It’s just how the work got done.

The risks are immediate and practical. Without control of these accounts, you can get blocked from deploying fixes, renewing the domain, paying hosting bills, rotating leaked keys, removing old access, or even getting support help because you can’t prove ownership.

When founders say they need to recover GitHub and hosting access, they usually mean moving from “I can see the app” to “I can change it, ship it, and secure it without asking anyone.” That’s the target.

Some parts are usually recoverable with the right steps. Repositories can often be transferred if the current owner cooperates, or exported and re-imported if they don’t. Hosting can often be recreated in a new account if you have the code, environment settings, and a way to point the domain to the new server.

Other parts can take longer. Domains are the big one. If the registrar account and registrant email aren’t yours, you may need support tickets, proof, and time. Email can be another blocker: if your “admin” email is actually the freelancer’s inbox or domain, resetting anything becomes painful.

Set expectations early: this is part negotiation (getting a clean transfer), part support ticketing (proving you’re the business owner), and part cleanup (rotating secrets, fixing deploys, removing risky shortcuts). If the project was generated quickly with AI tools and then patched by hand, you may also discover fragile code and exposed credentials during handover.

First 60 minutes: reduce risk before you touch ownership

Your goal in the first hour is to stop surprises. Before you ask for transfers or open support tickets, reduce the chance that anything gets changed, deleted, or billed without you noticing.

Pause deployments and work in progress. If a freelancer still has access, even a “quick fix” can overwrite settings, rotate secrets, or muddy the audit trail. Tell your team to stop merging and shipping until you know who controls what.

Then rotate what you can access right now. This is often the fastest way to reduce damage, even before ownership is fixed. Prioritize accounts that touch money, customer data, and authentication.

Do the basics first:

• Change app admin passwords and remove unknown admin users.
• Rotate database passwords/users and revoke old ones where possible.
• Re-issue API keys (payments, email, maps, analytics) and disable old keys.
• Update any environment variables you can reach.
• Turn on 2FA for accounts you already control.

After that, capture the current state. This isn’t busywork. If something changes later, you’ll need proof of what existed and who was paying for it. Take screenshots or exports from any dashboards you can still access, especially billing pages, repository permissions, DNS records, hosting settings, and CI/CD configuration.

Start an incident log immediately. Keep it plain and consistent, because support teams will ask for dates and evidence.

Write down:

• Dates and times (with time zone)
• Who you contacted (freelancer, agency, support)
• Where you contacted them (email, chat)
• What you requested (transfer, admin access, billing change)
• Ticket numbers and outcomes

Example: you can still log into Stripe and your app dashboard, but GitHub and hosting are under the freelancer’s email. In the first hour, you pause releases, rotate Stripe webhook secrets and app admin passwords, screenshot DNS records, and log the exact message you sent requesting a transfer. That puts you in a stronger position to proceed without guessing what changed.

Make an inventory of accounts, owners, and proof

Before you try to take anything back, write down what exists and who controls it today. This prevents you from missing the one account that can lock you out later (often the domain registrar, a shared email inbox, or a CI system).

List every service that touches your app. For many startups, that includes a repo host, hosting provider, domain registrar, email provider, database, and a handful of quiet tools like analytics and error tracking.

Use a simple format for each service:

• What it controls (code, DNS, servers, email, payments)
• Account email on file and display name
• Who pays and whose name appears on invoices
• 2FA method and who holds it
• Recovery options you know about (backup codes, recovery email/phone)
• Status: full access, partial access, or no access

Partial access matters. You might be able to see a repo but not manage org settings, or access hosting logs but not billing, or edit DNS but not transfer the domain.

Next, highlight what you already control. These are your anchors:

• A company email inbox you can log into
• The payment method being charged
• Any admin login you still have (even if it’s not the top-level owner)
• Domain access (domains often decide everything else)

Finally, collect proof you may need for support. Put it in one folder so you’re not scrambling later: invoices, bank or card statements, your contract or SOW, and message history where ownership and admin access were discussed. If you have company formation docs, keep those handy too.

How to ask the freelancer for a proper transfer

Treat this like a handover, not a breakup. You want a clean transfer with the least drama and the least risk. A calm, specific request usually gets a faster yes, especially if the freelancer thinks they’re being accused.

Make it easy to comply. Instead of “give me everything,” send a short list of actions, in order, with a time window. Also say you’ll confirm once you can log in and see the settings, so they know this ends cleanly.

What to ask for (in the right order)

Ask them to add you first, then transfer ownership after you verify. That keeps the project stable while access changes hands.

1. Add your email as an admin/owner on the GitHub org or repo, the hosting provider, and the domain registrar.
2. Confirm you can log in, view billing and permissions, and manage 2FA/recovery options.
3. Transfer ownership (repo/org, hosting project, domain) to your company email.
4. Share handover materials: repo clone, database dump, a list of current environment variables (don’t paste secrets into chat), deployment steps, and where logs/alerts live.
5. Remove their access only after you confirm everything works.

A line that keeps things smooth: “Please add me as admin first so I can verify nothing breaks, then we’ll do the ownership transfer right after.”

A message you can copy

“Hi [Name], we need a clean handover of the project accounts created under your email. Can you add [your email] as admin on GitHub, hosting, and the domain account today? Once I verify access, please transfer ownership to [company email]. Also please share a backup (repo clone, latest DB export) and basic deployment notes. Deadline: [date/time]. If you’re busy, tell me what time works and I’ll accommodate. If we can’t complete it by then, I’ll open support tickets with the platforms and review our contract so we can proceed without blocking the business.”

Keep everything in writing. If they push back, ask what part is difficult (time, missing access, uncertainty about what to transfer) and adjust the plan without changing the goal.

Step-by-step: transfer GitHub, hosting, domain, and 2FA

The goal is straightforward: you become the owner everywhere, and any hidden keys used for deploys and logins get replaced.

Do transfers in an order that avoids breaking production.

GitHub: move ownership without breaking deploys

Start by getting control of the GitHub organization where the code should live. If you don’t have an org yet, create one under a company-managed email.

Key steps:

• Have the freelancer add your company GitHub account as an Owner (not just a collaborator).
• Transfer each repository into the org.
• Rotate sensitive items (especially GitHub Actions and repository secrets). Assume anything the freelancer could see is compromised.
• Review deploy keys and any OAuth/GitHub Apps tied to the repo. Remove anything you don’t recognize and re-create keys under your control.
• Check branch protection so a former collaborator can’t push directly to main.

Before you rotate secrets, write down what deploys use today (CI provider, hosting target, environment names). This prevents an avoidable outage.

Hosting, domain, and 2FA: take control of the keys to the kingdom

Code ownership helps, but whoever controls hosting and DNS can still change what users see.

• Hosting/cloud: get added as the top-level admin/owner first, then move billing to a company payment method, then remove the freelancer.
• Team/workspace: where the platform supports it, move projects into a company team/org so access isn’t tied to one person.
• Domain/registrar: transfer the domain to an account you control and confirm you can edit DNS records. Also confirm who controls SSL/TLS settings and renewals.
• Company email: switch platform logins off the freelancer’s email and onto a company-controlled inbox.
• 2FA: rebind 2FA to your devices or a company-managed method. Regenerate backup codes and store them securely.

Sanity check after transfers: open an incognito window and verify your admin account can (1) change DNS, (2) change billing, and (3) deploy a test change. If any of those still depend on the freelancer, you’re not done.

When the freelancer is unresponsive: working with platform support

If the freelancer won’t reply, support is your next lever. The goal is to prove you’re the rightful business owner and get the asset moved into an account you control.

Write a short, consistent story you’ll reuse in every ticket. Keep it factual: what the project is, which accounts are blocked, who created them, when you paid, and what change you’re requesting.

What support usually needs from you

Most platforms ask for the same categories of proof:

• Payment proof (invoices, receipts, statements)
• Business proof (company registration, proof you represent the business)
• Domain control proof (ability to add a DNS record, access to billing email, registrar payment history)
• Account clues (usernames, org names, repo names, domain names, approximate creation dates)
• Security checks (billing address, last 4 digits of the card, support PIN if you have it)

When support replies with follow-up questions, answer in one clear message with labeled attachments (for example: “Attachment A - invoice”).

What to request (and what to avoid)

Ask for the smallest change that gives you control. Many support teams won’t “hand over an entire account” without very strong proof.

Requests that are often realistic:

• Add your email as an owner/admin on the org, repo, or hosting project
• Change the account email to a company-controlled address
• Help migrate repos, projects, or subscriptions to a new account you create
• Reset or remove 2FA only as part of a verified ownership process

Avoid vague requests like “Give me the account.” A better phrasing: “Please add my email as an admin so I can transfer ownership and rotate credentials.”

Timing varies. Some hosts respond within hours. Domain registrars and identity teams can take days and multiple back-and-forth replies. Plan for 2-5 business days, keep one ticket per platform, and keep your incident log updated.

Common mistakes that make recovery harder

The biggest trap is thinking “the site is up, so we’re fine.” A prototype can run and still be unsafe. Rushed builds often include exposed API keys, weak login rules, or admin routes that were never locked down. If you wait until after a breach to fix ownership, the same access problem turns into a security incident.

Another mistake is treating this like a password problem. If the freelancer created everything under their email, getting “the right password” doesn’t give you real control. You need ownership transfer: admin role, billing owner, domain registrant control, and 2FA that you manage.

Teams also trip over secrets. People change the hosting password but forget the tokens sitting in three other places. Before you move anything, identify where credentials exist:

• CI/CD settings (build pipelines, deploy keys, service tokens)
• Hosting environment variables (prod and preview)
• The repo itself (config files, old commits, sample .env files)
• Client-side code (anything shipped to the browser is effectively public)
• Third-party dashboards (payments, email, analytics, error tracking)

Backups get skipped because everyone wants to “just transfer it.” Then DNS records get overwritten, a database gets replaced, or repository history gets lost during a rushed export. Take a clean snapshot first: repo, database, storage buckets, and current DNS settings.

Finally, don’t make moves that trigger lockouts without a plan. Revoking access or changing emails too early can cause failed deploys or a defensive reaction. Move in a controlled order: confirm you can deploy and roll back, then transfer ownership, then rotate keys.

Quick checklist: are you safe yet?

“Safe” means the business can keep running even if the freelancer disappears today.

Start with the biggest single point of failure: your domain. If you can’t log into the registrar account, you don’t truly control your product. DNS changes can take your site and email offline quickly.

Use this as a practical check:

• Domain control: you can log into the registrar, edit DNS, and the domain can’t be transferred without your approval.
• Admin coverage: every critical platform has at least two admins you trust (not shared logins).
• Company identity: billing email, recovery email, and 2FA are tied to company-controlled inboxes and devices.
• Data safety: you have a recent repo clone, a database export, and a secure copy of required environment values.
• Deploy safety: you can redeploy from your own account, and you know exactly where the live app runs and who can access it.

If any item is “not sure,” treat it as “no.”

A simple reality test: write down the one login that would shut the company down if lost. For many teams, it’s the registrar, primary email admin, and code host owner. Fix those first.

Example scenario: a founder trying to regain control in 2 days

Maya is a solo founder. A freelancer built her MVP and launched it quickly: one GitHub repository (backend and frontend in one repo), a managed database on a hosting provider, and a domain pointing to a simple frontend. It works, but the freelancer created everything under their own email, and Maya has no admin access anywhere.

Hour 0 to 2 (stabilize): Maya reduces damage risk first. She screenshots anything she can find (billing emails, invoices, old credentials, domain renewal notices). She changes passwords on the accounts she does control (company email, payment portal) and pauses any auto-payments tied to services she can’t access.

By the end of Day 1 (collect proof and request transfer): Maya gathers proof the project is hers: the signed contract, payment receipts, the public site showing her brand, and the freelancer’s messages about setting things up. She sends a clear request: transfer the repo to her GitHub org, add her as the billing owner on hosting, and move the domain to her registrar account.

What she can do immediately vs what depends on others:

• Immediately: collect proof, secure company email, list services, prepare new owner accounts (GitHub org, hosting, registrar).
• Needs contractor: initiate transfers, add Maya as owner/admin, provide 2FA recovery codes or remove old devices.
• Needs platform support: forced domain recovery, repo disputes, or identity checks when the freelancer disappears.

Day 2 (rotate secrets and create a clean path): Once Maya has any access, she rotates anything that could be copied: database passwords, API keys, auth secrets, deployment tokens. If she can’t get access, she executes a fallback plan: create new accounts, restore from backups (or export what she can from the live app), and redeploy to infrastructure she owns. Then she writes a simple ownership map: who owns GitHub, hosting, domain, database, and 2FA.

Next steps: lock in ownership and prevent this next time

Once you regain control, don’t stop at “it works.” Make it hard for your product to get stuck behind one person’s email again.

Create a company-owned root identity that owns the essentials. Use a company-controlled inbox (often a shared admin mailbox on your domain) as the billing and recovery email for your domain registrar, GitHub org, and hosting accounts. Keep it boring and stable. It shouldn’t belong to a freelancer, and it shouldn’t depend on one employee’s personal inbox.

Set simple rules that match how real teams work:

• Keep at least two verified owners/admins on every critical account.
• Store recovery codes and license keys in a team password manager.
• Require contractors to use their own accounts as members, never as the owner.
• Use a short end-of-contract handover checklist (what they built, where it runs, how to deploy, where secrets live).
• Run a quarterly access drill: confirm you can log in and rotate a token without the original builder.

If your app was built quickly with AI tools or stitched together from prototypes, plan time for cleanup before you treat it like production. Ownership fixes are only half the story. Messy code and rushed deployments often hide problems like hard-coded secrets, broken auth flows, or unsafe database queries.

A practical approach: freeze changes for a day, move secrets into proper environment variables or a secret store, and write down one source of truth for deployment (where it’s hosted, how to deploy, what “healthy” looks like). Even one page of notes saves weeks later.

If you want outside help, FixMyMess (fixmymess.ai) specializes in taking broken AI-generated prototypes and turning them into production-ready apps. A quick audit can also surface common handover landmines, like exposed secrets, broken authentication, and deploy setups that only work from the original builder’s machine.

Treat account ownership as part of the product, not paperwork. Track access, owners, and recovery steps the same way you track bugs and features, so no single person can block the business again. "}