Bitwarden - Self-hosted password manager

lukaszj

murgero

@girish But building apps without the build service is already possible - do you mean that the manifest will allow us to specify a repo and docker image to install? Cause that would be nice!

girish

Just started looking into getting this package published. I also found a related https://github.com/dani-garcia/bitwarden_rs/pull/677 .

iamthefij

@girish I'd be neat if that gets merged, but the maintainers rejected a previous patch for direct LDAP support and that's why it was moved to a different binary. See comments here: https://github.com/dani-garcia/bitwarden_rs/pull/396#issuecomment-464059020

iamthefij

Hey @girish any updates on this? I've been holding off on migrating from my external instance to my Cloudron one because I'm not sure about the process of migrating from the dev one to an official one. Any guidance on when to expect this or if it's possible to preserve the Docker volume would be helpful.

will

@iamthefij said in Bitwarden - Self-hosted password manager:

Hey @girish any updates on this? I've been holding off on migrating from my external instance to my Cloudron one because I'm not sure about the process of migrating from the dev one to an official one. Any guidance on when to expect this or if it's possible to preserve the Docker volume would be helpful.

I'm in the same boat. I am maintaining a VPS solely for Bitwarden access. Would save $10 a month and time if I could roll this out! Thanks for all the hard work!

I tried deploying the Cloudron Bitwarden like below:

Commands run on Cloudron server.

git clone https://git.cloudron.io/fbartels/bitwardenrs-app #Successfully clones to home directory
npm install -g cloudron-cli **#Command fails, no cloudron-cli **
cloudron build # this will ask your cloudron.io login #Never got to this stage
cloudron install # this will ask you for your cloudron's login #Never got to this stage

murgero

@will Those commands do NOT get ran on the cloudron server.

The cloudron CLI is ONLY for use outside of the server (it's the management tool for cli users)

At home, install virtualbox on your computer and create an ubuntu VM. (If you already have a computer with linux, ignore this step, these steps can be installed in windows if you install nodejs and git first)

Then run:

git clone https://git.cloudron.io/fbartels/bitwardenrs-app
cd bitwardenrs-app
## Install NodeJS from https://nodejs.org/en/download/package-manager/
npm install -g cloudron
cloudron build
cloudron install

will

@murgero Thanks! I'm running windows subsystem for linux so I'll give it a shot. Thanks again!

murgero

@will If you plan on building apps using a local docker install, that can only be done on linux (not the subsystem), otherwise using a build service (either the app one or cloudron's cloud build service) is good on any system with nodejs support

will

@murgero I'm not a developer, but I have stumbled my way through rough spots before. Just so I understand the workflow.
So lets say I want to deploy the Bitwarden app on my Cloudron instance in production (I don't but let's roll with it for a sec)
I would configure my dev environment (install Nodejs, cloudron-cli, and install Cloudron build service app on the Web Store)
I would clone the app I wanted to play with to my local dev machine, cd into that directory and use the cloudron build command to bush this app to the Cloudron Build Service App?
Lastly use the cloudron install command to install the app on to my production instance.
How close am I to the right answer?

Thanks again for taking the time out to help me out. I'm trying to understand this stuff, but it's way out of my swimlane.

murgero

@will I don't use the build service app because it can delete other apps mistakenly. I use the following process for building my apps (step by step, literally) using a local linux machine with Docker, npm, git, and cloudron-cli.

Just make sure you have a free dockerhub account

git clone https://github.com/mitchellurgero/cloudron-vscode
cd cloudron-vscode

## Change as you need!
docker build -t dockername/projectname:tagname .
docker push dockername/projectname:tagname

## End docker changes
cloudron login
cloudron install --image dockerhuburl/dockername/projectname:tagname

Example commands when replacing the variables with real items:

git clone https://github.com/murgero/MyApp1-cloudron
cd MyApp1-cloudron

## Change as you need!
docker build -t murgero/MyApp1:latest .
docker push murgero/MyApp1:latest

## End docker changes
cloudron login
cloudron install --image dockerhuburl/murgero/MyApp1:latest

iamthefij

FYI @murgero @will I don’t think that git repo has any of the fixes or changes I’ve added. Try the one I linked much earlier. (I’m on mobile so I can’t link it now).

fbartels

@murgero building is much easier now. when you call cloudron build it will ask for the registry to upload to. so you just have to enter your-username/your-chosen-name-for-the image, e.g. fbartels/cloudron-bitwardenrs. cloudron install will then automatically use this image.

@will I am still not a huge believer in the ldap sync and the mysql backend of bitwarden. I have updated my repo to the last version and also picked some smtp things from @iamthefij. Sending invites still does not seem to work, will need to look further into this.

Edit: Managed to fix the issue with sending invites. the value of SMTP_AUTH_MECHANISM needs to be quoted, but when exporting it, these quotes are normally removed. Working and up to date version is in the git repo.

iamthefij

@fbartels what issues are you having with the LDAP sync?

fbartels

@iamthefij its not a technical problem, the approach isn't bad either. I think both (LDAP and MySQL) simply add unneeded complexity.

murgero

@fbartels said in Bitwarden - Self-hosted password manager:

building is much easier now. when you call cloudron build it will ask for the registry to upload to. so you just have to enter your-username/your-chosen-name-for-the image, e.g. fbartels/cloudron-bitwardenrs. cloudron install will then automatically use this image.

This requires the build service app to be installed on your cloudron which currently has a warning attached to it that it may delete USED docker images from other apps. Until the build service app is more stable, I'll stick to my sure-fire, tried and true way

fbartels

@murgero said in Bitwarden - Self-hosted password manager:

This requires the build service app to be installed on your cloudron

That is not true. Its build locally and then pushed into the github account.

iamthefij

@fbartels I see. Yea, totally agree that it’s not really necessary for most folks usage. The instance I run outside of Cloudron today uses neither of them. I’m using it as a simple personal password manager.

I believe Cloudron tends to prefer configurations that are ready for a small enterprise. My personal Gogs server was fine with SQLite and local auth as well, but Cloudron is configured with MySQL and LDAP.

‍️

yusf

I think it’s important to scale for at least 50 intended users for Cloudron apps. I think that this number is even specified in the docs somewhere.

necrevistonnezr

@fbartels said in Bitwarden - Self-hosted password manager:

@murgero said in Bitwarden - Self-hosted password manager:

This requires the build service app to be installed on your cloudron

That is not true. Its build locally and then pushed into the github account.

When I try to update my bitwarden app at the existing domain 'bit.mydomain.de' this way, I still get a

Failed to install app: 409 message: Domain 'bit.mydomain.de' is in use

I have a wildcard DNS entry), so a DNS entry for the subdomain should not cause trouble. I also tried cloudron login --allow-selfsigned but it doesn't change anything.

Could the "version" entry in CloudronManifest.jsonbe the culprit?

fbartels

@necrevistonnezr said in Bitwarden - Self-hosted password manager:

Could the "version" entry in CloudronManifest.jsonbe the culprit?

No, at least not from my experience. It always depends from where you installed an app previously. So for example when you initially installed an app from the official appcenter you can not easily update it with a locally build app. To make it recognize an existing app you can add the --app parameter to the install command.

So e.g. cloudron update --app bit

But make sure that the applications are actually compatible with each other.

necrevistonnezr

Still gettin errors:

osboxes@osboxes:~/bitwardenrs-app$ cloudron update --app bit
Will update app at location bit
 => Waiting for app to be updated 
 => Starting ... ...
 => Backup - Snapshotting app bit.mydomain.de ..
 => Backup - undefined 
 => Downloading image ...........................................
App update error: Installation failed: undefined

osboxes@osboxes:~/bitwardenrs-app$ sudo cloudron update --app bit
Will update app at location bit
Failed to update app: 409 message: Not allowed in error state

fbartels

@necrevistonnezr it seems to fail at downloading the image, so it has nothing to do with the app per se.

Can you also post the output of cloudron build?

Maybe it could also help to remove the existing app before (but since it fails at downloading I would doubt that).

necrevistonnezr

Output of cloudron build:

Building locally as necrevistonnezr/bitwardenrs:20191210-094936-34576695f

Sending build context to Docker daemon  114.2kB

Step 1/28 : FROM "bitwardenrs/server:1.13.0-alpine" as bitwarden
 ---> c0f785714c65
Step 2/28 : FROM cloudron/base:1.0.0@sha256:147a648a068a2e746644746bbfb42eb7a50d682437cead3c67c933c546357617
 ---> 534bd0efda10
Step 3/28 : ENV ROCKET_ENV "staging"
 ---> Using cache
 ---> 08e348a2d671
Step 4/28 : ENV ROCKET_PORT=3000
 ---> Using cache
 ---> 4f829684eb90
Step 5/28 : ENV ROCKET_WORKERS=10
 ---> Using cache
 ---> 4c341fbb8b34
Step 6/28 : ENV DATA_FOLDER=/app/data
 ---> Using cache
 ---> 624de75507eb
Step 7/28 : ENV CONFIG_FILE=/app/data/config.json
 ---> Using cache
 ---> df63ce28a824
Step 8/28 : ENV SIGNUPS_ALLOWED=false
 ---> Using cache
 ---> 98489eda2ecf
Step 9/28 : ENV INVITATIONS_ALLOWED=true
 ---> Using cache
 ---> 363bd3b89949
Step 10/28 : ENV WEBSOCKET_ENABLED=true
 ---> Using cache
 ---> c3ab1f3b150c
Step 11/28 : ENV DISABLE_ADMIN_TOKEN=true
 ---> Using cache
 ---> 57d590406e2c
Step 12/28 : RUN mkdir -p /app/data
 ---> Using cache
 ---> bf796d6b68b4
Step 13/28 : VOLUME /app/data
 ---> Using cache
 ---> af0388a6c7c5
Step 14/28 : EXPOSE 80
 ---> Using cache
 ---> c4e5fc4eef9c
Step 15/28 : EXPOSE 3012
 ---> Using cache
 ---> 0d3be2006979
Step 16/28 : RUN rm /etc/apache2/sites-enabled/*
 ---> Using cache
 ---> 128658526e5f
Step 17/28 : RUN sed -e 's,^ErrorLog.*,ErrorLog "|/bin/cat",' -i /etc/apache2/apache2.conf
 ---> Using cache
 ---> 460b63a85e66
Step 18/28 : RUN a2disconf other-vhosts-access-log
 ---> Using cache
 ---> b660416c4b47
Step 19/28 : COPY apache.conf /etc/apache2/sites-enabled/bitwarden.conf
 ---> Using cache
 ---> 380066c29b0c
Step 20/28 : RUN a2enmod ldap authnz_ldap proxy proxy_http proxy_wstunnel rewrite
 ---> Using cache
 ---> 5d85bcdb4449
Step 21/28 : COPY --from=bitwarden /web-vault /app/code/web-vault
 ---> Using cache
 ---> 8c8e6cd0a79a
Step 22/28 : COPY --from=bitwarden /bitwarden_rs /app/code/
 ---> Using cache
 ---> 23aa34133bc8
Step 23/28 : COPY --from=bitwarden /Rocket.toml /app/code/
 ---> Using cache
 ---> 16d854c4cdb4
Step 24/28 : ADD supervisor/ /etc/supervisor/conf.d/
 ---> Using cache
 ---> 94e6be8b3e39
Step 25/28 : RUN sed -e 's,^logfile=.*$,logfile=/run/supervisord.log,' -i /etc/supervisor/supervisord.conf
 ---> Using cache
 ---> a4b630549d9e
Step 26/28 : WORKDIR /app/code
 ---> Using cache
 ---> ac66a3410991
Step 27/28 : COPY start.sh /app/code/start.sh
 ---> Using cache
 ---> 8fee6c91fd4a
Step 28/28 : CMD [ "/app/code/start.sh" ]
 ---> Using cache
 ---> ebd0cc6480c9
Successfully built ebd0cc6480c9
Successfully tagged necrevistonnezr/bitwardenrs:20191210-094936-34576695f

[1mPushing necrevistonnezr/bitwardenrs:20191210-094936-34576695f[22m
The push refers to repository [docker.io/necrevistonnezr/bitwardenrs]
59ca39a8baf6: Preparing
d20566396bfd: Preparing
426f40b89686: Preparing
351495e80404: Preparing
205c5dee79e1: Preparing
4f9345d26f82: Preparing
ffd05eeb91b1: Preparing
5418b55c5d1d: Preparing
92cad9313b91: Preparing
0ea137c0c63c: Preparing
16ef7d4b2f8e: Preparing
f8a2b79c8722: Preparing
5648d21d9467: Preparing
bfe34f2cfbd0: Preparing
83a42f6af455: Preparing
f81e4eb4d80a: Preparing
cd78fba29389: Preparing
5662a07238a1: Preparing
8d7ea83e3c62: Preparing
6a061ee02432: Preparing
f73b2816c52a: Preparing
6267b420796f: Preparing
a30b835850bf: Preparing
5648d21d9467: Waiting
bfe34f2cfbd0: Waiting
83a42f6af455: Waiting
f81e4eb4d80a: Waiting
cd78fba29389: Waiting
4f9345d26f82: Waiting
5662a07238a1: Waiting
8d7ea83e3c62: Waiting
6a061ee02432: Waiting
ffd05eeb91b1: Waiting
5418b55c5d1d: Waiting
f73b2816c52a: Waiting
6267b420796f: Waiting
92cad9313b91: Waiting
0ea137c0c63c: Waiting
16ef7d4b2f8e: Waiting
f8a2b79c8722: Waiting
a30b835850bf: Waiting
351495e80404: Layer already exists
205c5dee79e1: Layer already exists
d20566396bfd: Layer already exists
426f40b89686: Layer already exists
59ca39a8baf6: Layer already exists
4f9345d26f82: Layer already exists
ffd05eeb91b1: Layer already exists
0ea137c0c63c: Layer already exists
16ef7d4b2f8e: Layer already exists
f8a2b79c8722: Layer already exists
92cad9313b91: Layer already exists
5418b55c5d1d: Layer already exists
5648d21d9467: Layer already exists
bfe34f2cfbd0: Layer already exists
f81e4eb4d80a: Layer already exists
5662a07238a1: Layer already exists
cd78fba29389: Layer already exists
8d7ea83e3c62: Layer already exists
83a42f6af455: Layer already exists
6a061ee02432: Layer already exists
f73b2816c52a: Layer already exists
6267b420796f: Layer already exists
a30b835850bf: Layer already exists
20191210-094936-34576695f: digest: sha256:ab443082901c6beac8d3e222448e20436b5e4d51c380bc2146f1f8d868ce06d4 size: 5114

And how do I get past the 409 message: Not allowed in error state?

fbartels

I don't know enough about the internal workings of cloudron to give a definite answer, but from what I see I would guess your first install failed (because it could seemingly not fetch the right image) and now the app is in a failed state.

One way to get out of this is to try restore an earlier backup (but it also said => Backup - undefined ) so its unclear if one exists, or remove the app and start anew.

necrevistonnezr

Thanks for the hint. In the control panel, I have the following error:

An error occurred during the operation: Docker Error: Unable to pull image. Please check the network or if the image needs authentication. statusCode: 404

necrevistonnezr

Stupid me! My docker repository was set to private!
Once made public - at least for the time of updating - a simple click on "repair" in the Cloudron control panel was enough!

fbartels

@necrevistonnezr then this here in the settings would probably be helpful for you:

moonmeister

For those using this. Does/will it support 2FA, and what kind? I'm mostly interested in Yubikey support. Thanks.

iamthefij

Yes. It supports a variety of 2FA including YubiKey.

d19dotca

Happy New Year everybody!

Just learned how to deploy a custom app using Bitwarden as the test, but seeing as it should be delivered soon, figured I'd wait for the more official release. So on that note... is there any ETA yet for this app @girish or @nebulon by any chance? If it's going to be a month or two I may start with the custom app, but figured if it'd be just another week or two (or just less than a month), then I'll just wait it out.

Thanks again for all the work you guys do - including everyone else in this thread, as I was able to learn a lot from reviewing everything you all wrote!

girish

Sorry for the delay, back to working on getting this published.

As a prelude, I have written to the upstream project to see if there is a chance of getting bitwarden (the .net project) working with a database other than MSSQL. As it stands, Cloudron cannot run the main project in a supported fashion.

Now for Bitwarden Rust, I built @iamthefij's project and it works great.

The current LDAP integration will essentially sync periodically and auto-invite users. I think this is awesome. However, Cloudron has a few limitations:

Apps are installed with 'all users' by default. This would mean all users on Cloudron will get invited/get email on installation. @iamthefij Maybe we can add a flag to not send email even if smtp is configured? My understanding is that this way LDAP users first have to 'create account' to get themselves an invite. Non-LDAP users won't get an invite. (https://github.com/dani-garcia/bitwarden_rs/wiki/Syncing-users-from-LDAP)
I guess we should disable users somewhere in https://github.com/ViViDboarder/bitwarden_rs_ldap/blob/master/src/main.rs#L107 when users go away from LDAP?

If 1 is not possible, I am also open to publishing the app without LDAP integrated directly. i.e we just include the binary and add docs to tell the user to run the command from the web terminal. That way they are aware email is going to be sent.

For 2, if you think that is outside the scope of an "invitation" system, then I think we should disable the ldap addon but include the bitwarden_ldap binary (this is just to be consistent with all our other apps wrt access control). We can add something in Cloudron to get credentials to the ldap server. That way, user can run the binary with the credentials directly.

d19dotca

@girish Do all users on the system automatically get invited? I didn't see that in my experience when I deployed the same app the other day, I had to manually invite myself through the /admin panel. I'm going to be a bit embarrassed if all my clients on the server got an email invite without me knowing

rmdes

@d19dotca other LDAP enabled apps never invite anyone and don't even create the profile/user before that particular user actually login..not sure if that answer your use case..

girish

My understanding of the way it works is: Each Bitwarden user has a "master" password (also the login password). This password is set by a user when they setup their account (via an invitation email - this is the only way to finish account setup). There is no mechanism to create a user with a pre-setup password (like changeme) on the server. This is because all the encryption/key generation happens on the clients. The clients get the master password, generate keys etc and just send it to the server.

What this means is that Cloudron/LDAP password cannot be used as a login mechanism for Bitwarden. What the LDAP integration in the current Cloudron package does is to basically get the list of all users in Cloudron via LDAP and just sends them invitation emails (it does this periodically). This way each user can click on the invitation email, setup a master password and start using Bitwarden. Because Cloudron apps are installed with "all users" access restriction as the default, this would mean that the LDAP integration sends invitation email to all Cloudron users. In addition, if you change Cloudron/LDAP password or even delete the user in Cloudron, there is no effect in Bitwarden. This is quite different from how all other apps behave.

@d19dotca does that clarify?

iamthefij

Should be possible, like some other apps, to have the option of enabling automatic invites or forego it.

Technically, user management is local to the application. Invites is all that is really happening.

It should also be possible to silently invite users. This means that any user can sign up in the application directly as long as their email has been added to the invite list. May have to patch the core application for that, but certainly doable. If this sounds preferable, I can look into that.

As for disabling customers, it should also be possible. It was also planned, but just not implemented yet. Disabling does sound risky though as cutting off access to a password manager could be extremely disruptive.

d19dotca

@girish Yes I think that clarifies then. Thank you for explaining it. I thought from your earlier post you meant that all LDAP users registered on the Cloudron server would automatically be invited to use Bitwarden and I was worried there for a second. haha. My experience is what you explained most recently in that the invite needs to be manually done through the Bitwarden admin area.

fbartels

@iamthefij said in Bitwarden - Self-hosted password manager:

This means that any user can sign up in the application directly as long as their email has been added to the invite list.

I think there was already an option to only allow signups from specific mail domains.

iamthefij

@fbartels yes. You can whitelist an entire domain. That will not allow whitelisting particular people on that domain though. So group or other constraints that we get with LDAP integration would not be supported.

The issue is that by default if sending mail is enabled Bitwarden will send an invite email with a particular invite code for any newly invited user: https://github.com/dani-garcia/bitwarden_rs/blob/88c56de97b48bb5b9b8af350d0d0e0d5f080ff0e/src/api/admin.rs#L163

An option to suppress this without disabling email entirely would allow whitelisting (and possibly revoking) users based on an LDAP query.

iamthefij

As a short term, I can enable the optionalSso manifest option and disable LDAP integration when the user specifies.

iamthefij

And done. Just pushed an update that allows disabling of SSO entirely and should fall back to the administrator manually inviting folks via the /admin page. I have not had a chance to test this though.

https://git.cloudron.io/iamthefij/bitwardenrs-app

girish

@iamthefij That was quick. Can you put in a LICENSE file into the repo (preferably MIT like the other app packages), so I can get this pushed to unstable?

The optionalSso still has the issue that it will trick people into thinking it behaves like other LDAP apps. I think Cloudron needs to have some enhancement here to make the UX work reliably. For a start, I can push it out with LDAP syncing in place (i.e a person who wants to can run the tool manually from the terminal) but ldap addon removed.

iamthefij

@girish they won't be able to run it on a schedule, will they? If it was possible to schedule that, it would be great.

I just made some more updates to the Description to explain user management. I also updated the env variables set so they can be overridden by users (through the DB, CLI, or some new interface) to allow open signups, block invites, or whitelist a particular domain.

I can also add an MIT license file as long as @fbartels agrees, since I based it on his repo.

fbartels

@iamthefij said in Bitwarden - Self-hosted password manager:

I can also add an MIT license file as long as @fbartels agrees, since I based it on his repo.

Almost forgot to reply here. I have added a license file to my repo now. So when you rebase yours you should get it as well.

will

@fbartels you are the man!

iamthefij

Awesome! Thanks @fbartels!

I've merged your changes in, switched back to the single stage build for speed (possible now that MySQL support is offered in a Docker image), and updated the Readme and Changelog.

I believe this "works for me" but someone else should validate as well.

necrevistonnezr

I'm trying to build and install the new version. After

cloudron update --app=bit.mydomain.com

I received the error

Docker Error: Unable to pull image. Please check the network or if the image needs authentication. statusCode: 404

Trying to restore the app that is now in an error state, I receive the same error. Docker is running, repository is set to public, I'm both logged in in cloudron and docker on the command line.

Any idea?

girish

@necrevistonnezr Is this after you did a cloudron build ? If you open up ~/.cloudron.json, it will have an apps section and inside that various paths. Can you check what the dockerImage in that is?

necrevistonnezr

@girish said in Bitwarden - Self-hosted password manager:

@necrevistonnezr Is this after you did a cloudron build ? If you open up ~/.cloudron.json, it will have an apps section and inside that various paths. Can you check what the dockerImage in that is?

Sorry, can't check that right now as I'm at work - but shouldn't I be able to at least restore the app?

iamthefij

@necrevistonnezr you can specify the image you want Cloudron to pull on the command line to your update command as well via --image=something/something:latest. This is what I do in the Makefile I added to allow me to use a more standard Docker workflow with pushing to Docker Hub and pulling from there.

necrevistonnezr

@girish said in Bitwarden - Self-hosted password manager:

@necrevistonnezr Is this after you did a cloudron build ? If you open up ~/.cloudron.json, it will have an apps section and inside that various paths. Can you check what the dockerImage in that is?

It says (anonymized):

 "apps": {
        "/Users/Username/Cloudron/bitwardenrs-app": {
            "repository": "myrepo/bitwarden",
            "dockerImage": "myrepo/bitwarden:20200122-061725-4544ff2bf",
            "dockerImageSha256": "00000fdbc13fa2f2d8edc85fc73b0d68c803b180a2287c19e03c3b25f453d6a97"
        }
    },

Those are the correct coordinates....

girish

@necrevistonnezr I have sent you an email to follow this up.

will

Is there any way I can help push this along?

jimcavoli

Likewise - this seems tantalizingly close to ready - and it's high up my list of things I'd like to get to deploying. What's the remaining to-do list or best way(s) to contribute at this point?

necrevistonnezr

bitwarden_rs 1.1.4 is out
https://github.com/dani-garcia/bitwarden_rs

Added support for running on subpath, simply add the subpath to the DOMAIN variable: DOMAIN=https://example.com/custom-path

Attachment size limits, per-user and per-organization, set USER_ATTACHMENT_LIMIT or ORG_ATTACHMENT_LIMIT to a value in kilobytes to apply it.

Updated U2F library which might solve some U2F certificate errors.

Added SMTP test button in the admin page.

Use web vault built by docker autobuild, using the hash to reference the image for extra security

Now accepting y/n, True/False, 1/0 as config options that are booleans.

Fixed error Unique constraint violation when using Two Factor and Postgres.

Fixed error with can_signup_user that didn't allow to change the email address.

Don't error if admin token is empty but disabled

Now email domains are converted to punycode before sending

Enable icons to be cached in the clients

Added option to change invitation org name

Enabled the sending of invitations from the admin panel, even when disabled

Dependency updates

will

@necrevistonnezr Bumping this app request, bitwarden is one of the last important holdouts in my cloud replacement efforts.

necrevistonnezr

@will fbartels version is fully functional (https://git.cloudron.io/fbartels/bitwardenrs-app), I've been using it for months now. And if you modify the bitwarden_rs build number in https://git.cloudron.io/fbartels/bitwardenrs-app/-/blob/master/Dockerfile before building, you get the newest version. I updated just yesterday.

Change

FROM "bitwardenrs/server:1.13.1-alpine" as bitwarden

to

FROM "bitwardenrs/server:1.14-alpine" as bitwarden

jdaviescoates

@necrevistonnezr given this @fbartels app works and is the most requested app, and the release of Cloudron 5 out of the way, and the goal for this year seems to be to get lots more apps released, I'm left wondering what is holding up getting this into the app store @girish @nebulon?

will

@necrevistonnezr I know you've talked about it in the past, do you have the thread where there are instructions on how to install it? DO I add that URL as a private git repo? Never did any custom app stuff before (well I tried and failed)

necrevistonnezr

@will said in Bitwarden - Self-hosted password manager:

@necrevistonnezr I know you've talked about it in the past, do you have the thread where there are instructions on how to install it? DO I add that URL as a private git repo? Never did any custom app stuff before (well I tried and failed)

Install & run Docker, it will ask you to log in or create a Docker account
Keep the Docker app / service running
git clone https://git.cloudron.io/fbartels/bitwardenrs-app and cd bitwardenrs-app
cloudron build(that's assuming you have installed cloudron cli via npm) - it will ask you for your cloudron credentials, and ask for your Docker repository, which should be set to public during the installation (makes it easier from my experience), e.g. in the form Docker_Username/bitwarden_rs
cloudron install: it will ask for the domain to install to, e.g. bit.domain.tld

If you update, it's pretty much the same, just git pullin the app directory, cloudron build, and then cloudron update --app bit.domain.tld

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Solved Bitwarden - Self-hosted password manager

Commands run on Cloudron server.