Jeremie Perreault

Hi Alex,

I’ve got an update on the two remaining points.

The DataProtection warning is harmless too. ASP.NET Core logs it because the container’s DataProtection key ring is stored in a folder that isn’t persisted or encrypted. DVLS doesn’t depend on that key ring: login cookies are encrypted with the key in encryption.config. If the container is recreated and generates new DataProtection keys, users stay logged in and no data is affected.

You don’t need to change anything for this warning. As before, encryption.config is the file to back up and keep safe.

I also checked with our Gateway team about the cipher suites. You can keep the nine-suite list. The important part is that the TLS 1.2 suites match your certificate’s key type:

• ECDHE_ECDSA_* suites require an ECDSA certificate.

• With your RSA certificate, the original five-suite list gave nginx no usable TLS 1.2 suite, so TLS 1.2 clients couldn’t connect.

• TLS 1.3 suites don’t depend on the certificate type, which explains why those clients still worked.

• RDM on macOS fell back to TLS 1.2 and offered ECDHE-RSA-AES256-GCM-SHA384, which wasn’t in nginx’s allowed list.

For a reverse proxy in front of Gateway, the team recommends TLS 1.2 and 1.3, with ECDHE + AEAD suites that match the proxy’s certificate. Mozilla’s intermediate profile is a good reference, and keeping the full nine-suite list is fine too.

One thing to keep in mind: Gateway’s HTTP listener can sit behind an HTTP reverse proxy, but its TCP listener can’t. nginx can forward raw TCP traffic, though you’ll need to test that in your setup if you plan to use it.

Hi Alex,

Sorry I didn’t follow up here sooner. The documentation was updated after my first reply, and I should have let you know. Thanks for the detailed test result, they helped a lot. Here are the answers and a few corrections.

1. Role privileges. My earlier answer was wrong, sorry. CREATEDB is not enough, on a fresh database, the schema creation changes PostgreSQL type casts, which requires SUPERUSER. I reproduced it on DVLS 2026.3.11.0 with PostgreSQL 17.11: initialization fails with 42501: permission denied for table pg_cast when the role isn't superuser. What you did is the right workaround:

ALTER ROLE dvls_user SUPERUSER;

-- run the container once with DVLS_INIT=true

ALTER ROLE dvls_user NOSUPERUSER;

DVLS doesn't need superuser at runtime. We've logged this as a bug so that initialization works with a dedicated non-superuser owner role.

2. NOSUPERUSER for future upgrades. Only the initial schema creation needs superuser. The current upgrade steps don't change casts or require superuser, so an instance initialized the way you did should upgrade with a NOSUPERUSER owner, as long as that role owns the DVLS objects (which it does when it ran the initialization). We're fixing the initialization issue and adding a check that runs schema creation and upgrades as a non-superuser role. If a future version ever needs elevated rights for an upgrade, it will be called out in the release notes.

3. SSL mode. I was wrong here too; the documentation is correct. The mapping is:

- DATABASE_ENCRYPT=false → SSL Mode=Disable

- DATABASE_ENCRYPT=true + DATABASE_TRUST_SERVER_CERTIFICATE=true → SSL Mode=Require

- DATABASE_ENCRYPT=true + DATABASE_TRUST_SERVER_CERTIFICATE=false → SSL Mode=VerifyFull

4. Backup. pg_dump and pg_restore are not in the image yet; that's a known issue. The job reporting success and writing a zip without the database dump is a separate problem: it should fail. I am logging that too. Until it's fixed, keep running pg_dump from the PostgreSQL side as you're doing now.

5. DVLS_ENCRYPTION_CONFIG_B64. If App_Data is on a persistent volume, the container works without it: initialization writes encryption.config to App_Data and reuses it on every start. We still recommend setting it, or at least keeping a secure copy of encryption.config outside the volume. That file is the only key to the encrypted data in the database, so if the volume is lost or recreated, the data can't be recovered.

6. Startup warnings behind a proxy. "Failed to determine the https port for redirect" is expected with WEB_SCHEME=http behind a TLS-terminating proxy, and it's harmless.

7. Gateway TLS cipher suites. TLS isn't my area of expertise, so I've asked our Gateway team to confirm the recommended configuration and will update this thread with their answer. From what we've looked at so far: in TLS 1.2, the cipher suite has to match the certificate type, so with an RSA certificate only the ECDHE_RSA_* suites can be used. The five suites you configured don't include any ECDHE_RSA suite, which would explain why RDM on macOS failed over TLS 1.2 while the nine-suite list (which includes the three ECDHE_RSA suites) works. In the meantime, the nine-suite list from the Gateway system requirements page for Devolutions Server is the one to use.

Thanks again for the thorough testing.

Hi nicolosantorso,

Thank you for the detailed report, and sorry for the trouble.

You were right that a step was missing: the first schema creation, done by Update-DPSDatabase, needs the Devolutions Server role to have the PostgreSQL SUPERUSER attribute. The other two errors (dbo.databaseinfo and dbo.useraccount / dbo.usersecurity do not exist) come from that first failure: the schema was never created.

The guide now covers this: https://docs.devolutions.net/server/kb/how-to-articles/devolutions-server-for-linux/

We have also opened an internal ticket to remove the superuser requirement during installation.

To fix your current install:

1. Drop the partially created database, then recreate it, keeping the same owner.

2. Give the role superuser rights:

ALTER ROLE <dvls_user> SUPERUSER;

3. Run Update-DPSDatabase, New-DPSWorkspaceSettings and New-DPSAdministrator again.

4. Once installation is complete, remove the superuser right:

ALTER ROLE <dvls_user> NOSUPERUSER;

Let us know if you run into anything else.

Best regards,

Hi Alex,

Thanks for the detailed report. Your reading of the binary is correct, and the Docker and Linux documentation is behind. Here are the answers:

1. DATABASE_TYPE

Yes, DATABASE_TYPE=PostgreSQL is supported in Docker. Accepted values are SqlServer (default), PostgreSQL and SQLite, case-insensitive. MSSQL and Postgres also work as aliases. Your assumed configuration is right:

-e DATABASE_TYPE=PostgreSQL

-e DATABASE_HOST=pg.example.com

-e DATABASE_PORT=5432 # optional, defaults to 5432 for PostgreSQL

-e DATABASE_NAME=dvls

-e DATABASE_USERNAME=dvls_user

-e DATABASE_PASSWORD='...' # or DATABASE_PASSWORD_FILE

2. SSL

There are no PostgreSQL-specific variables. The existing ones map to the Npgsql SSL Mode:

- DATABASE_ENCRYPT=false (default): no SSL Mode is set, so the Npgsql default Prefer applies.

- DATABASE_ENCRYPT=true and DATABASE_TRUST_SERVER_CERTIFICATE=true: Require (encrypted, certificate not validated).

- DATABASE_ENCRYPT=true and DATABASE_TRUST_SERVER_CERTIFICATE=false: VerifyFull (certificate and host name validated).

3. Database creation

You don't need to create it first. With DVLS_INIT=true, DVLS connects to the postgres maintenance database and creates the target database if it's missing, so the role needs CREATEDB. Otherwise, create the database beforehand with that role as owner. Only a single owner role is supported for now.

4. pg_dump / pg_restore

These tools are not included in the image, so the built-in PostgreSQL database backup won't work out of the box. I've opened an internal ticket to close this gap. Until it's fixed, build a derived image that installs postgresql-client with a major version equal to or newer than your server's. You can also mount the binaries and point DVLS_PG_DUMP_PATH / DVLS_PG_RESTORE_PATH at them.

5. Supported versions

PostgreSQL 14 or later, self-hosted or managed.

6. Documentation

We've reported the gap to the documentation team so the Docker and Linux guides get updated.

Also note that the Linux image applies pending schema upgrades at startup by default (DVLS_DATABASE_UPGRADE_ON_STARTUP=true).

Best regards,

Hi @bbaranowski ,

From what you've described, you've actually identified the root cause. The Invalid column name 'AccountExpirationDate' error is what we expect to see when a 2026.x server starts against a database that hasn't been migrated yet. The 2026.x server expects schema changes (like the AccountExpirationDate column) that don't exist in a 2025.3 database, and the group membership issue is another symptom of the same schema mismatch.

The missing step is the database migration. The server container doesn't perform schema upgrades automatically when it starts. Instead, the migration has to be run as a separate, one-time step before starting the new server. This is intentional so the upgrade is explicit and a database backup is taken first.

To answer your questions:

• No, you don't need to upgrade through intermediate versions. You can upgrade directly from 2025.3 to 2026.2.11. That's why trying 2026.1.22 produced the same error—the issue wasn't the version jump, it was that the database hadn't been migrated yet.

• No, a direct version upgrade doesn't automatically migrate the database. The migration container needs to be run explicitly.

One important point: since you're upgrading an existing database, you'll want to use update mode (DVLS_UPDATE_MODE=true), not init mode. Init mode is only for creating a brand-new database. Update mode backs up your existing database, applies the schema changes, and then exits. DVLS_INIT and DVLS_UPDATE_MODE are mutually exclusive.

The upgrade process should look like this:

1. Restore your 2025.3 database snapshot so you're starting from a consistent state.

2. Pull the 2026.2.11 image.

3. Stop and remove the old server container.

4. Run the image once in update mode (DVLS_UPDATE_MODE=true), making sure you've configured a backup path/volume. The container will back up the database, apply the migration, and then exit.

5. Once the migration completes successfully, start the main server container normally.

The complete procedure, including the required environment variables and a Docker Compose example, is documented here under Version updates:

https://docs.devolutions.net/server/knowledge-base/how-to-articles/devolutions-server-docker-deployment/advanced-docker-configuration-for-devolutions-server/#version-updates

I also noticed that your docker-compose.yml contains a commented-out dvls_init section. Could you confirm how you're currently running the migration container? For an upgrade of an existing database, it should be running in update mode, not init mode.

Hi,

As Erica mentioned, it appears that you are using an earlier version of DVLS. This feature was introduced in version 2025.3.

You can find an example of how to log in and retrieve the token in Bash at the end of the following page : https://docs.devolutions.net/server/web-interface/utilities/api-documentation/

If you upgrade to the latest version, you can follow this documentation to configure and use the API key : https://docs.devolutions.net/server/kb/how-to-articles/generate-api-keys/

Best regards,

Jérémie Perreault

Hi,

I thought we already had documentation on this, but I wasn’t able to locate it. Here are the steps required to use API keys with the public API:

1. Enable API keys in System Settings → Users → Allow API Key.

2. Enable API key usage for your specific user under Administration → Users → Modify User → Settings → Allow API Key.

3. Generate your key by clicking your profile picture in the top-right corner, then navigating to Preferences → API Key → Generate New API Key.

Once this is done, you can use the API key directly as a Bearer token in the Authorization header. No login or additional tokens are required. For example:

curl -H "Authorization: Bearer $APIKEY" \
     https://dvls.example.com/endpoint

Let me know if you need anything else.

Best regards,

Jérémie Perreault

Hello sjames,

You’re not the first to mention that this part can be a bit confusing, and we completely get it. Thanks for pointing it out, it’ll be taken into consideration as I’m working on the fix right now.

Best regards,

Jeremie