Update self-hosting documentation

[Z4Y]

Barely any documentation has been updated to V4, there are no usable docker files, the docker-compose.yml is over a year old, and there aren't any particularly clear instructions on how to get up and running. As previously stated, the instructions that we do have at the moment are very outdated and I've had quite a bit of trouble trying to get myself a self-hosted instance.

[MaKleSoft]

It's true that the docs are a little sparse for v4. We're a small team so please bear with us. We'll get around to it, I promise :)

In the meantime, have you tried any of these examples? https://github.com/padloc/padloc/tree/main/docs/examples/hosting/docker

[BrunoBernardino]

As @MaKleSoft said, the official docs at https://docs.padloc.app/guides/self-host/ point to those 3 examples using Docker which are up-to-date and confirmed working by a few people already. Can you explain what have you tried, what have you found missing, and what errors you found? That should help us improve.

[Z4Y]

One problem I'm facing for some reason is a constant loading screen on the web server, I'm not sure why but this is just with the basic docker configuration.

[BrunoBernardino]

Can you check the browser's console log? That or the server logs should have something to help figure out what's up.

[Z4Y]

Can you check the browser's console log? That or the server logs should have something to help figure out what's up.

Loading failed for the <script> with source “http://10.1.1.34:8080/main.js”. [10.1.1.34:8080:65:1](http://10.1.1.34:8080/) Content Security Policy: The page’s settings blocked the loading of a resource at http://10.1.1.34:8080/main.js (“script-src”). Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). moz-extension:42:9 Content Security Policy: The page’s settings blocked the loading of a resource at http://10.1.1.34:8080/favicon.png (“img-src”).

[BrunoBernardino]

Can you try accessing it via http://localhost:8080 instead (that's what that basic config expects)?

If you don't want to access it via localhost, you'll need to set PL_PWA_URL and PL_SERVER_URL properly for pwa, in your case, next to/below https://github.com/padloc/padloc/blob/main/docs/examples/hosting/docker/basic/docker-compose.yml#L26 and like:

pwa:
        image: padloc/pwa
        build:
            context: github.com/padloc/padloc.git#main
            dockerfile: Dockerfile-pwa
        environment:
            PL_SERVER_URL: http://10.1.1.34:3000
            PL_PWA_URL: http://10.1.1.34:8080
        ports:
            - 8080:8080
        restart: on-failure

Let me know if that helps.

[working-name]

Update: using the docker + nginx thing worked because the app really gets requests from its own verifiable localhost I suppose. So, it sorta works. Now to figure out how to get accounts created and actually test the thing.

Let me know if that helps.

It does not unfortunately. I tried switching to WSL2's internal IP, then windows machine's own IP, then localhost, then made up a domain padloc.test and mapped it to 127.0.0.1 and in all cases it fails, even when localhost matches.

Note that the script-src blob: value doesn't change from localhost no matter what you place in the docker-compose.yml

padloc.test as PL_SERVER_CLIENT_URL and PL_SERVER_URL

Refused to load the script 'http://padloc.test:8088/main.js' because it violates the following Content Security Policy directive: "script-src blob: http://localhost:8080/". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

padloc.test/:1 Refused to load the image 'http://padloc.test:8088/favicon.png' because it violates the following Content Security Policy directive: "img-src http://localhost:8080/ blob: data: https://icons.duckduckgo.com".

localhost as PL_SERVER_CLIENT_URL and PL_SERVER_URL

Refused to load the script 'http://localhost:8088/main.js' because it violates the following Content Security Policy directive: "script-src blob: http://localhost:8080/". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

localhost/:1 Refused to load manifest from 'http://localhost:8088/manifest.623e2268f17398ec7f19225e281e4056.json' because it violates the following Content Security Policy directive: "manifest-src http://localhost:8080/".

localhost/:1 Refused to load the image 'http://localhost:8088/favicon.png' because it violates the following Content Security Policy directive: "img-src http://localhost:8080/ blob: data: https://icons.duckduckgo.com".

[BrunoBernardino]

@working-name I'm not sure what to do about the IP matching in Windows, but as for the CSP error, what's used in it is PL_PWA_URL, not PL_SERVER_URL, and that's what I suggested you set above.

If you set that and it's not being picked up, can you share your full docker-compose.yml file?

[working-name]

what's used in it is PL_PWA_URL, not PL_SERVER_URL, and that's what I suggested you set above.

Update: PL_PWA_URL does work if you change the host-side port, browser is happy.

Yes, I just figured it out: it was the port number. I mapped 8088 to internal 8080 and that's why the error. If I leave it on 8080 for both host and app then it's fine either with PL_PWA_URL set or without it. If I swap all 8080 ports in the docker-compose to 8088 the app still stubbornly tries to start on 8080 given its logs, and the browser gets an empty response.

version: "3.7"
services:
    server:
        image: padloc/server
        build:
            context: github.com/padloc/padloc.git#main
            dockerfile: Dockerfile-server
        environment:
            PL_DATA_BACKEND: leveldb
            PL_DATA_LEVELDB_DIR: /data
            PL_DATA_ATTACHMENTS_BACKEND: fs
            PL_DATA_ATTACHMENTS_DIR: /attachments
            PL_SERVER_CLIENT_URL: http://localhost:8088
        ports:
            - 3000:3000
        volumes:
            - attachments:/attachments
            - data:/data
        restart: unless-stopped
    pwa:
        image: padloc/pwa
        build:
            context: github.com/padloc/padloc.git#main
            dockerfile: Dockerfile-pwa
        environment:
            PL_SERVER_URL: http://localhost:3000
            #PL_PWA_URL: http://localhost:8088
        ports:
            - 8088:8088
        restart: on-failure
volumes:
    data:
    attachments:

With the above YML the app will initialize like so:

pwa_1     | > http-server ${PL_PWA_DIR:-dist} -s -p ${PL_PWA_PORT:-8080} --proxy ${PL_PWA_URL:-http://0.0.0.0:${PL_PWA_PORT:-8080}}?

[BrunoBernardino]

I agree it's not obvious which of the variables you need to set and which are optional (or even necessary/unnecessary in combination), but it's hard to allow people to experiment and get this running themselves, and allow them to go through more complex setups, while keeping documentation easy to read and parse (to support the cases above). In any case, the port would always be necessary to set via PL_PWA_PORT if you're trying to remap it and not setting PL_PWA_URL, as per

padloc/packages/pwa/webpack.config.js

Line 13 in 5f1264a

const pwaUrl = process.env.PL_PWA_URL || `http://localhost:${process.env.PL_PWA_PORT || 8080}`;

Can I close this, or is there something you'd like to suggest we improve on, here?

[working-name]

Oh it's not my ticket, but if I were to suggest an improvement it is to add PL_PWA_URL in the simple docker sample config.

As far as keeping documentation easy to read and parse ... not sure I agree with that. Documentation's goal is to help you get things running. Looking pretty while failing at its main job doesn't make up for it 😄

I'm thinking you probably don't want to undermine income potential by making it too easy for folk to selfhost. Then again, have no clue if your app even works because I can't get past the confirmation email - set up .env given another user's public gist of how to run your app and emails don't seem to be sent that way either. Don't know if any of your apps can take a custom server URL either. I'll most likely give up on trying it out, but looks nice from the screenshots though, good job.

[BrunoBernardino]

Oh it's not my ticket, but if I were to suggest an improvement it is to add PL_PWA_URL in the simple docker sample config.

Thanks, I'll add that soon.

I'm thinking you probably don't want to undermine income potential by making it too easy for folk to selfhost.

Quite the contrary. By making it easier to self-host, we reduce the time we spend on support. We have plenty of people self-hosting it who have shared their opinion on having it been the easiest password manager to self-host so far, and while that experience isn't universal, we're interested in making it the most common.

Then again, have no clue if your app even works because I can't get past the confirmation email

If you don't want to enable emails via SMTP, you can have them printed to the console with the PL_EMAIL_BACKEND=console variable. That will allow you to see the confirmation code as per

padloc/packages/core/src/messenger.ts

Line 125 in 5f1264a

console.log(`Message sent to ${recipient}: ${JSON.stringify(message.data)}`);

Don't know if any of your apps can take a custom server URL either.

We chose not to, to prevent abuse and to make the setup easier. Anyone who forks the repo should be able to setup all the environment variables with the Google/Apple/Microsoft certificates/keys and generate their own apps to distribute how they please.

[MaKleSoft]

I'd like to add to what @BrunoBernardino said.

Yes, the current setup/configuration is quite confusing, but that's mostly because the number of configuration options has increased dramatically with and since the v4 release, and we simply haven't been able to catch up with the documentation. I also think that the current way of configuring the server instance (env variables all the way down) is not optimal and needs to be supplemented with something less error-prone and easier to use.

Going forward the plan is to use json config file as the default way of configuring the server instance, with environment variables overriding said config file and providing a way to handle secrets more securely. This will come with a fairly detailed json schema which will effectively make it self-documenting and easier to trouble-shoot. Here is the corresponding issue: #603

In principle, the goal is to make Padloc the easiest to deploy self-hosted password manager out there, period. I think we still have a ways to go to achieve that, but architecture-wise we have a pretty solid foundation to make this happen.

Let me reiterate that we are a small team and constantly have to make decisions as to where to put our focus at any given time. If the documentation around self-hosting leaves something to be desired (which it currently does), that is not because we want it harder for people to self-host. The project is already licensed under AGPL which we believe provides enough motivation for potential enterprise customers to acquire a commercial license. As for everyone else, we see Padloc as a gift to the community.

[lumeyisnotyou]

Something else that is sort of related, the process of building the native apps is far too convoluted. Is there any specific reason that you can't just build in functionality to set a custom server? I'd love to migrate to this, but I've yet to get any builds working, and iOS is just not happening, period.

[dillfrescott]

@lumeyisnotyou Any open source app that doesn't have an option to change the server in the mobile apps seems to be trying to discourage self hosting it.

I'd suggest using Bitwarden, which has this feature, and more.