Let's start with the fact that your site redirects to HTTPS but you do not have a valid TLS certificate (it is expired). This will always cause your browser show you a connection error. You can fix that very easily in your hosting control panel. After all, you are using a free of charge Let's Encrypt certificate like all of us; your hosting control panel has a way to renew it. If you do not know how, ask your host.
The fact that we get an HTTP 301 redirection to HTTPS when we try to access any URL on your site over plain HTTP tells me that for sure you have a .htaccess file for this kind of redirection can only be implemented in either the .htaccess file, or the server's virtual host configuration. Please do remember that dot-files (files whose name starts with a dot) are hidden. Unless you explicitly tell your FTP/SFTP client or hosting control panel file manager to show you hidden files you won't see it. A very simple way around it is to upload an empty file named .htaccess.
As I said, and since I see that you are running on an Ubuntu server (which is an odd choice for a commercial host), is it possible that you are self-hosting, or at the very least using a server someone else is managing for you? If so, what would normally be in the .htaccess file would be in Apache's virtual host configuration. This can include the aforementioned redirect from HTTP to HTTPS, as well as blocking access to .php files including Kickstart itself. If uploading the blank .htaccess file did not work for you, ask your host / server admin if this is the case.
If that did not help, do remember what I have written in the documentation:
Do not restore in a subdirectory of your main site. For example, if your site's root is in public_html do not restore to public_html/dev. The reason is that the .htaccess files, which tell Apache (your web server) how to server your site, cascade. That is, Apache will read all .htaccess files in all folders leading to the one hosting your site's index.php file. This will cause problems with the restored site which you will experience as 404, 403 and 500 error messages or blank pages. These have nothing to do with our software and / or the restoration. It's how your web server works. Use a subdomain instead.
If you are restoring on a subdomain, make sure that the subdomain's root directory is NOT a subdirectory of your main site. This is the same as the previous paragraph, really. Most hosting control panel software default to using a subdirectory of your site's root when creating a subdomain. For example, if your site is www.example.com and its root is public_html if you create the subdomain dev.example.com your hosting control panel will put its root in public_html/dev. Therefore you will have the problem we described above. In this case ask your host what is the best way to create a root folder for the subdomain next to public_html, not inside it.
If you are using a subdirectory or subdomain to restore your site, that would be the problem. If that's the case, please provide further information about your directory structure and whether you are using Admin Tools' .htaccess maker on the main site so I can guide you further.
Now, I want to address your complaint:
you need to create a much better restore method that doesn't get impacted by akeeba tools or better still doesn't require Apache / web server to be functional
You mean like what has been in place for the past 18 to 20 years?
Remember that the first thing you see in the documentation is this:
Akeeba Backup is a complete site backup solution for your Joomla!™ powered website. It will take a copy of your entire site – files and database data – and put it in a backup archive file. You can restore the backup archive file on the same or a different site, even a completely different server. The restoration uses a web installer script. The installer script is included in the backup archive itself.
In other words, all backup archives taken by Akeeba Backup are fully self contained: they have your site's files, a copy of your database, and the restoration script. That's how this software has worked for the past 20 years. And I repeat: twenty years. Since Joomla 1.0, when it was called JoomlaPack. This is the core design philosophy of this software since its first stages of inception, all the way back in 2004. All you need to do is somehow extract the backup archive and transfer all extracted files into the hosting account where you are restoring your site into. And, boy, do I ever give you tonnes of alternatives to do exactly that!
Regarding restoring when Apache is completely dead or not even installed, I have been doing that for 18 years if you would please pay attention. From 2008 to 2025 there was Akeeba UNiTE which would do a full unattended restoration using nothing but the CLI. All you needed was the CLI PHP binary and a functioning database server (of course!).
What bugged me is that you needed a separate script (UNiTE) to do that, and that UNiTE itself was doing too much: remote backups, backup downloads, and restoration. That was confusing. Since earlier this year (2025), this CLI restoration functionality is rolled into the Akeeba Backup Restoration Script, reducing your dependency count even further. All you need is extract your backup archive using Kickstart in CLI mode, set up your restoration information YAML file, and let BRS go to town with it, all from the CLI. I spent three months on reimplementing the restoration script. I never expected to make me more money, nor it ever did for that matter, but I did it anyway because I care.
But I digress. Let's go back to the web interface, for there are many alternatives and, as you will soon see, if you want to eschew using my software to restore a backup you absolutely can do that. It's not gonna be fun, and there are easier ways to go about it, but I do give you that option because who am I to dictate your use case?
So, let's see what are your options.
The most common BUT NOT THE ONLY option is uploading the backup archive and Kickstart into it. It works for 99% of use cases, and that's what I recommend most people use. Remember, this is most typical and easiest for most people, but far from the only option. Do not conflate popularity and/or ease of use with availability.
The integrated restoration is just the same as above, just dressed differently. Insert the "Corporate wants you to find the differences between these two pictures" meme from (the American knockoff of) The Office. The integrated restoration uses a headless version of Kickstart with the client-side interface being rendered inside Joomla. That's all. In both cases, the archive is extracted and you're redirected to the /installation directory where it extracted the backup restoration script which was included in the backup archive itself.
But here's the thing. As Kickstart tells you every time it starts, it's just an archive extraction tool. The actual restoration script is in the backup archive. Corollary: you just need to extract the backup archive somewhere, somehow, and get the extracted files into your site. The extraction does not have to take place on the same site, or even server. And the backup archive does not necessarily have to be a JPA or JPS file. You see where I am going with this?
Sticking to the beaten path, but perhaps straying off towards its more overgrown edges, we have another option. You can restore on a different server and take a backup as a ZIP file. Upload that ZIP file on your host and extract it using your host's tools. Try to access the site and you'll see the restoration script. This, by the way, was how Akeeba Backup worked back when it was still called JoomlaPack in the Joomla 1.0 era, twenty years ago. Why not still use it? Not only it's more steps, but it takes f o r e v e r to upload the tens of thousands of files a modern Joomla site consists of. A simple, empty installation of Joomla 6.0.0 with just Akeeba Backup Professional installed transferred over a gigabit connection to a server across the office (sub-1msec latency) takes the better part of 15 minutes. Extracting the same backup archive directly on the same local server takes, um, under five seconds. That's why I made Kickstart in 2008. Still, the OG option of manually uploading files has, does, and will exist as it's made possible by the core design philosophy of the backup system I have developed.
Now we're stepping a bit further into the bushes. We can extend the previous method, without an intermediate restoration. You can use Kickstart on any server, live or local, to extract the backup archive. When you reach the point where it says "Run the restoration script" stop. Upload the extracted files into your live server instead. For a local server you can install something like XAMPP, MAMP, WAMPserver etc on your computer. For a live server, just create a subdomain, making sure its web root is OUTSIDE your main site, as noted in the documentation I pasted above. Again, the annoying thing about this method is that transferring the files to the live server over (S)FTP happens at a glacial pace. I hope you understand that I am not responsible for the 50-year-old FTP protocol, or the nearly 40-year-old SFTP protocol as I am about to turn 45 which means I wasn't even born for the former, and barely into kindergarten for the latter.
But that's not all! Let's leave the beaten path and go straight into the woods. You have more options. As I mentioned, you can use Kickstart on the command line. If you are handy with a terminal, SSH into your site, cd into your site's web root, and run php kickstart.php your_backup_archive.jpa where kickstart.php is the name of your Kickstart file and your_backup_archive.jpa is the name of your backup archive file. Once the backup archive is extracted, you can of course go to your browser and use the web interface – or use the CLI-based restoration. Whatever floats your boat.
If you want to completely forego the beaten path, and all sense of sanity and self-preservation, I have you covered! Even if all else fails you can still restore your site as documented with the unorthodox emergency restoration. I have seen a small handful of use cases where this was actually necessary, and we are talking about some really messed up sites and servers.
Finally, even if you do not want to use Kickstart to extract your backup archives, I have both documented the JPA and JPS archive format, and give you the option to eschew that altogether using the ZIP archive format (even providing an alternative which DOES NOT use any of my code, instead using PHP's ZipArchive class).
If you are dead set against using any of my code to make your life easier restoring a site you can take a backup in the ZIP format, and implement the unorthodox emergency restoration procedure using nothing but system tools (unzip and sed), which works when you do not have Apache or PHP installed on your server; you only need a MySQL-compatible database server to restore the database (which should be fairly obvious).
So, what exactly are you asking me? Is this not enough?
😉
