You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The aliasvault script is ready for testing: bash -c "$(curl -fsSL https://github.com/community-scripts/ProxmoxVED/raw/main/ct/aliasvault.sh)"
Default credentials:
Username: admin
The initial installation builds AliasVault from source and takes 15–30 minutes. Do not interrupt the process.
The admin password is auto-generated during installation and displayed in the installation output. Save it immediately.
To receive alias emails, configure your domain's MX record to point to this server and update PRIVATE_EMAIL_DOMAINS in /opt/aliasvault/.env.
Note: This is not in the official repo yet—it's just a dev version! After merging into ProxmoxVE, it will need to be recreated.
Turns out the most recent release fixes the dependencies but breaks the workaround in this script for artifacts. Seems they fixed those build issues too.
PR aligns the build environment in this script with the upstream.
Switch to Debian 13 might be opinionated but I cannot see a reason to run an incubator script witch an old version the PVE Host no longer supports.
I ran the update for 0.30.3 two weeks ago and it went smoothly with the adjustments from the prior version.
✔️ Update available: aliasvault 0.30.2 → 0.30.3
✔️ Stopped Services
✔️ Backed up data to /opt/aliasvault.backup
✔️ Deployed: aliasvault (0.30.3)
⏳ Building Core Libraries (Patience)info: component rust-std for target wasm32-unknown-unknown is up to date
🚀 Starting build process for selected modules...
SNIP
✔️ Built AliasVault Applications
✔️ Restored data
✔️ Started Services
✔️ Updated successfully to 0.30.3!
That's for the good news.
I then adjusted my setup to test this in a more production-ready context ... and I was shocked to learn that it seems to completely fall apart.
The TLDR
I don't think the script can work as it is now. And it is not something that MickLesk & Co could easily (i.e. with justifyable effort) because it is more about how AliasVault is built (literally as well conceptually), not about the PVE script itself.
The long story
I don't feel like putting to much time into this, but I think it might be helpful for others to review/falsify/verify my findings.
What did I mean with "production-ready context"
My assumption is, that anyone seeking to run AliasVault via this helper script / in a LXC already has some kind of setup with services that should be re-used instead of just running the huge official AIO-container which (in the best case) only adds redundant services (e.g. the database) or in the worst case interferes with your existing setup or company policies (proxy, certificates, authentication).
That is, I assume a user of this script is looking for embedding the core of AliasVault into their existing environment and make it publicly available via existing resources. I. e. using an existing reverse proxy with TLS termination, optionally with some authentication middleware/policy to restrict access to internal services.
Early findings
When running the web interface on a local IP from your testing setup, like 'https://192.168.123.123/', it mostly works, but there are already some parts that don't work (and never will), because browsers block them when using self-signed certificates.
So let's focus on using domain names from now on. This should be a relevant info if you - like me - sometimes exclude the admin path from public access. I don't think that is an option for AliasVault. You need the admin ui to be accessible when you need it, not just to hope that it still works via IP when you need it.
Making AliasVault available via reverse proxy / domain name / auth
Usually pretty straight forward. Find the service port (if you are unsure, just check the ports from the official docker compose file), point the reverse proxy to it and let it snatch a shiny certificate for the new (sub)domain (or use your company wildcard).
At this point, it will not work. Let's go over the additional config needed:
Trusted Proxy: We need to tell AliasVault that the reverse proxy is allowed to provide additional header information
Backend Service Redirect: We need to tell AliasVault to stop redirecting the HTTP port to the internal HTTPS port (exposing the local IP to the public and breaking the proxy connection)
Authentication: Troubleshoot AliasVault requesting some resources outside of the existing browser session thus loosing access to them.
We need this setting, because the default is true.
Again, this does not work and cannot work. The entrypoint.sh has two nginx templates, one forcing a redirect of anythin on HTTP to HTTPS and one with separate endpoint configurations.
The helper script ignores all of that and just includes its own nginx template including the forced redirect.
Short break
At this point, I tried to fix the setup by calling the entrypoint with the same context to let it do its job. The idea is to not have any hardcoded template in the helper script because something as crucial as the webserver config should always align with the official build as much as possible. Otherwise, if the upstream changes things like compression settings or security settings or header, regressions in Proxmox installations resulting from a different server template will be incredibly hard to troubleshoot.
The hostname_marker is faked to prevent any ssl generators in that script from executing.
The result needs some fixes for our container context like this
sed -i "s|/usr/share/nginx/html|/opt/aliasvault/client/wwwroot|" /etc/nginx/nginx.conf
sed -i "s|include /etc/nginx/ssl.conf;|ssl_certificate /opt/aliasvault/certificates/ssl/cert.pem;\\n ssl_certificate_key /opt/aliasvault/certificates/ssl/key.pem;\\n ssl_protocols TLSv1.2 TLSv1.3;|g" /etc/nginx/nginx.conf
sed -i "s|client:3000|127.0.0.1:3000|" /etc/nginx/nginx.conf
sed -i "s|api:3001|127.0.0.1:3001|" /etc/nginx/nginx.conf
sed -i "s|admin:3002|127.0.0.1:3002|" /etc/nginx/nginx.conf
sed -i '/proxy_pass http:\/\/client;/a\ try_files /index.html =404;' /etc/nginx/nginx.conf
sed -i '/proxy_pass http:\/\/client;/d' /etc/nginx/nginx.conf
This approach is tested and works, but it is only some proof of concept. The entrypoint also starts the nginx service in a loop for the docker container so it is not meant to be just called as config script like this.
Back to Authentication
I added a random auth middleware to the reverse proxy to simulate any policies that will often be in place when exposing confidential services.
From my testing, you will not be able to use it (Password, PIN, SSO, whatever).
After authenticating with the proxy first and then logging into AliasVault you can see in the proxy logs and console that AliasVault accesses tons of web resources. Most (>95%) work over your proxy-authenticated browser session (otherwise you would not be able to access the AliasVault UI at all), but not all. Unfortunately, one is a call to the api to fetch the vault.
That means, you cannot secure AliasVault with a middleware because it knocks itself out with some strange core requests. (Other calls to the same endpoints work, so it's not some misconfigured middleware).
Two more points I came accross while testing this:
The local backend design
I did not give it much thought until I came across stack traces of database connection hickups in the browser console while testing the connectivity issues above.
Not some API calls or some upstream "DB connection error" information. No, the database queries (think database login information) to the remote Postgres server are made from the browser app, not between the server backend and the database server.
What is happening here?
My guess: This is because AliasVault tries to combine two different services that are conceptually absolutely incompatible with each other:
The password safe: This is a zero-knowledge vault. It is downloaded to the users local browser and can only be decrypted and managed there with the users private key (that's the offline mode, as advertised). The backend cannot be involved in any of this. It would not be able to process any of the data.
The email aliases: In its core function, this would be a backend-only service. The server receives e-mails, saves them in the database and/or forwards them to another mailbox. This would work without any frontend involved.
But what happens if you are advertising that you provide both at the same time? If you want to keep the promise that the user works fully offline in their local vault copy, you need to move the backend operations to that local context. Like a local second backend.
Security wise and conceptually, this feels and looks like a nightmare.
Which lead to the last point;
Shipping a truckload of .NET internals to the world
This one might be highly opinionated / personal preference. So take it with a grain of salt, but for me, it stuck.
Because the "local-backend-to-remote-backend" communication happens from the browser over the internet, the remote backend is public for everyone. If you examine the /opt/aliasvault/client/wwwroot/ webroot, the _framework folder alone contains the whole dot net framework and a lot more.
If I had to compare this, it feels like publishing a bursting node_modules folder and deploying it.
The attack vector is huge. All while we are dealing with .NET with lots of vulnerabilities and the dependencies complex enough to keep it from being constantly up-to-date.
Well, that's it for now.
As you can see, I was really looking forward to this. I had AliasVault on my list for some time and I really hope lanedirt succeeds with his idea. Let's hope I got the key points wrong.
//update: just now while finishing this text, v0.30.4 was released 👀 I'll just run the update, but I won't test it beyond that
//update2: it hang up midway and now the installation is no longer recognised. Haven't done a reinstall yet.
Setting config vars in .env (or anywhere) does not work
Hardcoded nginx template means this will never work with reverse proxies + TLS termination
Core app breaks upstream auth middleware
Core app breaks backend frontend convention because of offline vault idea
Personal:
.NET / wasm approach is "unique", to put it neutral. The app may be OSS, but I cannot imagine how a "community" would evolve around this and take up in case the main author "does something" unwanted. Thus does not fit well with the PVE Helper feeling in general.
As I’ve already said, AliasVault is simply unusable the way it’s built. Either you check with the upstream developers to see if they provide prebuilds and allow local execution—like vaultwarden (which will probably never happen)—or you’ll just have to do a massive amount of coding to get it to work. The way the script is currently built, it works locally; I haven’t given any thought to TLS/SSL/HTTPS—since the tool is simply broken time and time again.
Conclusion: I think it's better off in Docker; that saves us all the frustration and stress of even getting this tool to run. Compared to Vaultwarden, it's absolutely a nightmare to configure.
Sorry for repeating what has already been known. I must have missed it :(
Maybe you could link what you said/found in your first post? That way the current verdict is easily accessible for new people seeking it out.
I'd even go as far as saying this script should not exist on the helper script website catalog. Is that triggered by "Ready for testing"? Then I vote for changing the label.
Activity
github-actions commentedon May 17, 2026
The aliasvault script is ready for testing:
bash -c "$(curl -fsSL https://github.com/community-scripts/ProxmoxVED/raw/main/ct/aliasvault.sh)"Default credentials:
Username: admin
The initial installation builds AliasVault from source and takes 15–30 minutes. Do not interrupt the process.
The admin password is auto-generated during installation and displayed in the installation output. Save it immediately.
To receive alias emails, configure your domain's MX record to point to this server and update PRIVATE_EMAIL_DOMAINS in /opt/aliasvault/.env.
Note: This is not in the official repo yet—it's just a dev version! After merging into ProxmoxVE, it will need to be recreated.
King3R commentedon May 17, 2026
The admin area cannot be accessed.
The regular login page can be accessed without any problems, but you cannot create a vault because the username validation process fails.
MickLesk commentedon May 18, 2026
Can you try again? Should fixed both
MickLesk commentedon May 18, 2026
look okay now for me. But Work state of the E-Mail Function is unknown
King3R commentedon May 18, 2026
The admin area looks good, but the login credentials are no longer displayed during installation.
MickLesk commentedon May 18, 2026
Yeah, cat /root/aliasvault.creds
Havnt Update the json for now
King3R commentedon May 18, 2026
I could have figured that out myself. It's working for me now. The update works too.
CerberusStyle commentedon Jun 1, 2026
Install and Web UI work, update function also working as expected.
Note: Just needs that info updating so that admin password is shown. :)
mon5termatt commentedon Jun 4, 2026
Can attach log if needed.
MickLesk commentedon Jun 4, 2026
Hm new Version?
CerberusStyle commentedon Jun 4, 2026
One sec let me have a look.
EDIT: Unable to reproduce the above error my testing completes as expected as before. ( Install, WebUI and Update)
mon5termatt commentedon Jun 5, 2026
This was an advanced install with a vlan and custom static IP, thats basically all i changed. let me rerun the script.
mon5termatt commentedon Jun 5, 2026
https://youtu.be/Uj6r743uARg?t=240
Same error.
https://gist.github.com/mon5termatt/94f84674de9a32cfa675f1dd4feda81b
https://gist.github.com/mon5termatt/e551c7bdf0550fb8699aad306d912c01
CerberusStyle commentedon Jun 5, 2026
Run the install with default settings, does it then complete?
48 remaining items
MickLesk commentedon Jul 23, 2026
Again vulnerabilities in their Code
codeshell commentedon Jul 28, 2026
I wanted to try it out and it failed differently.
Turns out the most recent release fixes the dependencies but breaks the workaround in this script for artifacts. Seems they fixed those build issues too.
PR aligns the build environment in this script with the upstream.
Switch to Debian 13 might be opinionated but I cannot see a reason to run an incubator script witch an old version the PVE Host no longer supports.
Feel free to adjust as you see fit.
codeshell commentedon Aug 16, 2026
I ran the update for 0.30.3 two weeks ago and it went smoothly with the adjustments from the prior version.
That's for the good news.
I then adjusted my setup to test this in a more production-ready context ... and I was shocked to learn that it seems to completely fall apart.
The TLDR
The long story
I don't feel like putting to much time into this, but I think it might be helpful for others to review/falsify/verify my findings.
What did I mean with "production-ready context"
My assumption is, that anyone seeking to run AliasVault via this helper script / in a LXC already has some kind of setup with services that should be re-used instead of just running the huge official AIO-container which (in the best case) only adds redundant services (e.g. the database) or in the worst case interferes with your existing setup or company policies (proxy, certificates, authentication).
That is, I assume a user of this script is looking for embedding the core of AliasVault into their existing environment and make it publicly available via existing resources. I. e. using an existing reverse proxy with TLS termination, optionally with some authentication middleware/policy to restrict access to internal services.
Early findings
When running the web interface on a local IP from your testing setup, like 'https://192.168.123.123/', it mostly works, but there are already some parts that don't work (and never will), because browsers block them when using self-signed certificates.
Example:
So let's focus on using domain names from now on.
This should be a relevant info if you - like me - sometimes exclude the admin path from public access. I don't think that is an option for AliasVault. You need the admin ui to be accessible when you need it, not just to hope that it still works via IP when you need it.
Making AliasVault available via reverse proxy / domain name / auth
Usually pretty straight forward. Find the service port (if you are unsure, just check the ports from the official docker compose file), point the reverse proxy to it and let it snatch a shiny certificate for the new (sub)domain (or use your company wildcard).
At this point, it will not work. Let's go over the additional config needed:
Trusted Proxy
According to https://github.com/aliasvault/aliasvault/blob/main/.env.example all you have to do is set
TRUSTED_PROXIESaccordingly, e.g. in/opt/aliasvault/.envOr even add it as a LXC environment variable in Proxmox?
Well, it does not matter. I does not work and it cannot work. That config is not used when starting or restarting the AliasVault services.
Instead, the official docker container calls an https://github.com/aliasvault/aliasvault/blob/main/apps/server/entrypoint.sh script on start that recreates the whole nginx server configuration every time the container is started / restarted, using that ENV var.
The helper script does not use this entrypoint so
/opt/aliasvault/.envcannot work as expected.Similar with the following.
Backend Service Redirect
When using a reverse proxy with TLS termination, the backend service must not enforce any HTTPS related endpoint on its own.
According to https://github.com/aliasvault/aliasvault/blob/main/.env.example all you have to do is set
FORCE_HTTPS_REDIRECT=false, e.g. in/opt/aliasvault/.envWe need this setting, because the default is true.
Again, this does not work and cannot work. The entrypoint.sh has two nginx templates, one forcing a redirect of anythin on HTTP to HTTPS and one with separate endpoint configurations.
The helper script ignores all of that and just includes its own nginx template including the forced redirect.
Short break
At this point, I tried to fix the setup by calling the entrypoint with the same context to let it do its job. The idea is to not have any hardcoded template in the helper script because something as crucial as the webserver config should always align with the official build as much as possible. Otherwise, if the upstream changes things like compression settings or security settings or header, regressions in Proxmox installations resulting from a different server template will be incredibly hard to troubleshoot.
The hostname_marker is faked to prevent any ssl generators in that script from executing.
The result needs some fixes for our container context like this
This approach is tested and works, but it is only some proof of concept. The entrypoint also starts the nginx service in a loop for the docker container so it is not meant to be just called as config script like this.
Back to Authentication
I added a random auth middleware to the reverse proxy to simulate any policies that will often be in place when exposing confidential services.
From my testing, you will not be able to use it (Password, PIN, SSO, whatever).
After authenticating with the proxy first and then logging into AliasVault you can see in the proxy logs and console that AliasVault accesses tons of web resources. Most (>95%) work over your proxy-authenticated browser session (otherwise you would not be able to access the AliasVault UI at all), but not all. Unfortunately, one is a call to the api to fetch the vault.
That means, you cannot secure AliasVault with a middleware because it knocks itself out with some strange core requests. (Other calls to the same endpoints work, so it's not some misconfigured middleware).
Two more points I came accross while testing this:
The local backend design
I did not give it much thought until I came across stack traces of database connection hickups in the browser console while testing the connectivity issues above.
Not some API calls or some upstream "DB connection error" information. No, the database queries (think database login information) to the remote Postgres server are made from the browser app, not between the server backend and the database server.
What is happening here?
My guess: This is because AliasVault tries to combine two different services that are conceptually absolutely incompatible with each other:
But what happens if you are advertising that you provide both at the same time? If you want to keep the promise that the user works fully offline in their local vault copy, you need to move the backend operations to that local context. Like a local second backend.
Security wise and conceptually, this feels and looks like a nightmare.
Which lead to the last point;
Shipping a truckload of .NET internals to the world
This one might be highly opinionated / personal preference. So take it with a grain of salt, but for me, it stuck.
Because the "local-backend-to-remote-backend" communication happens from the browser over the internet, the remote backend is public for everyone. If you examine the /opt/aliasvault/client/wwwroot/ webroot, the
_frameworkfolder alone contains the whole dot net framework and a lot more.If I had to compare this, it feels like publishing a bursting
node_modulesfolder and deploying it.The attack vector is huge. All while we are dealing with .NET with lots of vulnerabilities and the dependencies complex enough to keep it from being constantly up-to-date.
Well, that's it for now.
As you can see, I was really looking forward to this. I had AliasVault on my list for some time and I really hope lanedirt succeeds with his idea. Let's hope I got the key points wrong.
//update: just now while finishing this text, v0.30.4 was released 👀 I'll just run the update, but I won't test it beyond that
//update2: it hang up midway and now the installation is no longer recognised. Haven't done a reinstall yet.
mon5termatt commentedon Aug 17, 2026
holy wall of text. love how the TLDR doesnt actually explain anything
codeshell commentedon Aug 17, 2026
Lol, you are right. Let's try again
Personal:
Does that make sense?
MickLesk commentedon Aug 17, 2026
As I’ve already said, AliasVault is simply unusable the way it’s built. Either you check with the upstream developers to see if they provide prebuilds and allow local execution—like vaultwarden (which will probably never happen)—or you’ll just have to do a massive amount of coding to get it to work. The way the script is currently built, it works locally; I haven’t given any thought to TLS/SSL/HTTPS—since the tool is simply broken time and time again.
Conclusion: I think it's better off in Docker; that saves us all the frustration and stress of even getting this tool to run. Compared to Vaultwarden, it's absolutely a nightmare to configure.
codeshell commentedon Aug 17, 2026
Sorry for repeating what has already been known. I must have missed it :(
Maybe you could link what you said/found in your first post? That way the current verdict is easily accessible for new people seeking it out.
I'd even go as far as saying this script should not exist on the helper script website catalog. Is that triggered by "Ready for testing"? Then I vote for changing the label.
github-actions commentedon Aug 17, 2026
⏸️ This script has been deferred. The Discord testing thread has been locked. Re-add the
Ready For Testinglabel to resume testing.jwklijnsma commentedon Oct 12, 2026
why not planned ?
MickLesk commentedon Oct 12, 2026
why cant read the conversation above?