I built LastSignal because I was uncomfortable trusting a third party with extremely sensitive information (final messages, recovery instructions, etc.).
LastSignal is a self-hosted dead man's switch: you prepare encrypted messages that are automatically delivered to chosen recipients if you stop responding to periodic check-ins.
Security-wise, the server is treated as untrusted by design:
- messages are encrypted client-side
- the server never sees plaintext
- the operator cannot decrypt stored data
I've documented the security model, threat assumptions, and known limitations here:
This is an early but usable version. I'm especially interested in feedback on the threat model, edge cases, and assumptions around liveness and delivery.
Currently the search engine we offer with HardyPress is very simple: we index the site content during the deploy process and we provide APIs to retrieve results (or you can use our native modal box with no additional coding).
Regarding plugins, currently about 90% of the plugin we reviewed are fully compatible, because the do not have any dynamic behavior on the frontend. If your site use some plugins marked as "incompatible", our system suggest you an alternative to replace the plugins behavior.
I perfectly understand your concern about HardyPress being a new "hosting provider", but HardyPress infrastructure is entirely built on the cloud, currently on Amazon AWS and the static generated sites are hosted on Amazon S3 Buckets that we use as pull-zones for the CDN, so your websites are really unbreakable and they'll stay up, no matter what!
You don’t need to trust us to feel safe!
If you want to have full control of your data you can always download your static generated site and host it somewhere else as your wishes. In this way you will use HardyPress only as a Static Site Generator plus the benefits that we will proxy your contact forms, and we'll make the search work!
Plugin support is a real challenge... anyway we are seriously building a white list of compatible plugins, and so far they are about 90% of the total. For the remaining 10% it is usually always possible to replace them with some external service (facebook-comments or disqus for comments, our Zapier app for mailchimp/drive/dropbox integration, beds24 as booking system, etc)
We also thought about something like your idea (keep a second installation live somewhere to submit the data), but, as you will have to host your real WP somewhere, you will lose one of the main benefits of HardyPress, namely to have your site unbreakable.
Ok, about this we will release soon a new feature where users will be able to deploy their static site on a custom ftp/sftp server.
Adding a git repo as destination won't be a problem :-)
I see your point, but I also think that most of the value in what we are offering here is the ability to turn WordPress on/off on demand, so you can forget about it after the changes.
How could this be achieve without hosting files and DB?
Actually there are a couple of things that I'd like to clarify:
1) There is no WordPress backend to maintain as it doesn't exists unless you turn it on in a temporary/hidden/virtual environment to make your changes. For the rest of the time it simply doesn't exists. No PHP, no MySql, nothing that can break. You don't even need to keep your installation updated if you don't want to.
2) The pages are not served from an S3 bucket but from a CDN with 20 edge server around the world. The bucket is only a "source of true" where the CDN loads the files when the "cache" is invalidated. This reduce the TTFB (Time to first byte) up to 10x from any location respect a traditional hosting service.
There are already some plugins that "staticize" your website, but
1) you still need to have and maintain secure the WordPress Installation somewhere. With HardyPress WP can be paused and restored when needed with a click.
2) you have to download the static version and upload it somewhere else manually (your client certainly can't do it on their own). HardyPress does it with a click.
3) contact forms and search will stop working. With HardyPress, if you use CF7, everything will work seemlessy.
To solve the problems above HaryPress needs to hosts your WP installation.
Actually with those plugin you still have some drawback: first you still need to have and maintain secure the live WordPress installation somewhere, second you have to download the static version and upload it somewhere else, last but not least your contact forms and search will stop working.
There is huge differences between running a live WordPress site on a docker container (where you still have php, mysql, etc), and running it as a static site in a serverless environment.
Actually yes, we are a new hosting company, but the live site is hosted an a AWS-S3 bucket with a CDN in front of it, so, even if you don't trust us, I could feel quite safe with it.
In my personal experience, I used to have a web agency with dozens of WordPress installation to keep alive, mostly of them where simple “brochure” sites. I used auto-update mechanisms and caching layers provided by the hosting service, but it happened more than once to have security/performance/technical problems and headaches.
Only after I put the static copy of these sites online I started sleeping well at night. There was no way that things could go wrong.
Of course it is easier if you build them with the "static solution" in mind. Anyway you will find a compatibility list of the plugin you are using on the site dashboard once your site is on HardyPress.
Yes, there are some plugins that "staticize" your website, but
1) you still need to have and maintain secure the WordPress Installation somewhere. With HardyPress WP can be paused and restored when needed with a click.
2) you have to download the static version and upload it somewhere else manually (your client certainly can't do it on their own). HardyPress does it with a click.
3) contact forms and search will stop working. With HardyPress, if you use CF7, everything will work seemlessy.
To solve the problems above HaryPress needs to hosts your WP installation.
The "admin" lives in a random-generated subdomain, is basic-auth protected and is alive only for the time needed for the editor to make the changes through the dashboard. For the rest of the time WordPress simply doesn't exist.
"Most WordPress websites are just "brochure websites": they don't expose anything dynamic to their visitors excluding comments, contact forms and search functionality. We already handle these scenarios out-of-the box. Also, every plugin you use that does not have any front-facing components, it's perfectly fine. It's not a hosting solution for every possible WordPress website out there, but it can handle a huge slice of the market, with big benefits for agencies/freelances."
Maintenance problems are those you have when you need to update your installation but you can not because the update break stuff around. I had lots of these :-)
I built LastSignal because I was uncomfortable trusting a third party with extremely sensitive information (final messages, recovery instructions, etc.).
LastSignal is a self-hosted dead man's switch: you prepare encrypted messages that are automatically delivered to chosen recipients if you stop responding to periodic check-ins.
Security-wise, the server is treated as untrusted by design:
- messages are encrypted client-side
- the server never sees plaintext
- the operator cannot decrypt stored data
I've documented the security model, threat assumptions, and known limitations here:
https://lastsignal.app/security/
Source code:
https://github.com/giovantenne/lastsignal
This is an early but usable version. I'm especially interested in feedback on the threat model, edge cases, and assumptions around liveness and delivery.
Happy to answer questions.