Skip to main content
Blog

Laravel/

Your developer left: how to get your Laravel app and hosting back

Developer left your Laravel project? Recover your domain, hosting, code and keys in the right order, and know when to call in help. A practical guide.

Ajay Kumar

Ajay Kumar

Web Developer

Your developer has gone quiet and your Laravel app still runs the business. You can get it back without their help, as long as you recover access in the right order.

In short

  • Recover access in this order: domain registrar, DNS and email, hosting, code repository, the .env secrets file, database backups, then every third-party service the app talks to.
  • Start with the domain. Almost every other account resets its password by email, and that email usually lives on your domain.
  • You do not need the old developer to begin. Read access to the code and the server is enough to assess the app. Change nothing until you hold the keys and have restored a backup at least once.
  • This works for apps on any Laravel version. It does not settle an ownership dispute. If your contract never assigned you the code, talk to a lawyer before anyone touches it.
Empty desk at night with a packed cardboard box, a closed laptop and a coffee mug

Who this is for

You paid someone to build a Laravel app, or you inherited one with the business. It works. Orders come in or staff log in every day. Then the developer stops answering, leaves the agency, or sends a last invoice and goes silent. Now you realise you cannot say where the app is hosted, who owns the domain or where the code lives.

Which accounts to recover, and in what order

Work down this list. Each item depends on the ones above it.

OrderAssetWhere to lookWhy it comes here
1Domain registrar accountInvoices, bank statements, the ICANN lookup toolPassword resets for everything else go to email on this domain
2DNS and email providerRegistrar nameserver settingsShows where the site and the email actually point
3Hosting or server accountInvoices, DNS records, the server's IP addressRuns the app and holds the live .env
4Code repositoryGitHub, GitLab or Bitbucket, plus the server's deploy folderThe only copy of your source code might be on the server
5Secrets and .env fileLive server, deploy toolDatabase, mail, payment and API credentials
6Database and backupsHosting panel, backup storageYour data. Prove a backup restores before anything else changes
7Third-party servicesStripe, mail provider, storage, analytics, error trackingOften registered under the developer's own email

To find the domain, look it up with the ICANN lookup tool to see which registrar holds it and what registrant details are listed. Many registrations are privacy-protected, so the listing may show nothing useful. If so, search your inbox and your accounting software for registrar invoices. A renewal receipt tells you the registrar and the billing email.

One exception to the order: if you already hold the hosting login but not the domain, start with hosting. Copy the live .env and take a backup the same day, then chase the domain.

What if the code is in your developer's personal GitHub account?

Often the repository sits under the developer's own username, not under a company account you control.

The fix is a repository transfer, and only someone with admin rights on the repository can start it. According to GitHub's documentation, issues and pull requests move with the repository, webhooks, secrets and deploy keys stay attached to it, and the original owner is added back as a collaborator. That last detail matters. After the transfer you must remove the old developer's access yourself, and rotate any deploy keys and tokens they could still reach.

If the developer will not transfer it, you have two options. Ask them to add you as an admin collaborator, which is a smaller request than a full transfer. Or have your contract reviewed. Who owns the code depends on what you signed and where you are, so do not assume the client owns it by default. We are engineers, not lawyers, so get legal advice if the contract is silent.

Do not rotate the app key first

Once you have the server, the instinct is to change every password at once. Do it in stages. One secret in particular can hurt you.

Laravel encrypts every cookie, including session cookies, with the APP_KEY value, along with any data your app encrypts itself. The Laravel encryption docs say that if you change it, all signed-in users are logged out, and data encrypted with the old key can no longer be decrypted. Laravel does offer a graceful rotation: list the old key in APP_PREVIOUS_KEYS so the app can still read old values while it writes new ones.

So the order is: copy the current .env somewhere safe, take a backup, prove the backup restores, then rotate. Rotating the database password, mail credentials and API tokens carries less risk than the app key, but each one needs a matching change in the service that issued it.

What to check once you have read access

Before you plan any work, find out what you are holding. Three questions matter: which Laravel and PHP versions run in production, whether the dependencies have known security advisories, and whether a deploy still works.

php artisan --version
php -v
composer audit

The first two print the framework and PHP versions. composer audit reports known advisories against the installed packages. Compare the versions with the Laravel and PHP support dates. An app on an end-of-life version still runs, but it gets no fixes, and the eventual upgrade gets harder every year you wait.

What recovery costs and how long it takes

Recovering access mostly depends on other companies: registrars, hosts and their support queues. The bigger cost usually comes afterwards, from catch-up work such as an upgrade, missing tests, or a backup process that never existed.

At Spectivis the first step is a free Laravel app takeover review. We read the code, the server and the deploy setup without changing anything, then send a written handover report and a fixed quote for any catch-up work. You only pay if you approve the quote. If the app needs a version upgrade, that is a separate fixed-price job through our Laravel upgrade service. Ongoing care afterwards is the $49 a month maintenance plan for apps with up to 10,000 tracked records, or managed hosting from $99 a month with the care plan included.

When we would not recommend a takeover

Try the simple route before you hire anyone, us included. If the developer is slow but reachable, send one clear email listing exactly what you need: registrar login or transfer, hosting access, repository admin rights, the .env file and the latest database backup. A short, specific list is easier to answer than "please send everything", and it leaves a paper trail.

A takeover is also the wrong move in three cases. If you cannot show that you own the code, settle that first. If the app is small, barely used and written in a way nobody can maintain, a rewrite may cost less than a rescue, and we will say so after the review. And if the app is not Laravel, our takeover service does not cover it.

What to do next

Write down which of the seven assets you can reach today. Then email the developer one specific request and keep a copy. If a week passes with no answer, tell us what you have and what you are missing. We will map a recovery path and tell you honestly whether the app is worth keeping.

If you are about to hire a new team, what to ask before you hire covers what to put in the contract so this does not happen again.

Sources