在服务端数据库的方案中，文档需要进一步说明避免用户落到坑里

[breakstring]

📦 部署环境

Vercel

📌 软件版本

1.1.6

💻 系统环境

macOS

🌐 浏览器

Edge

🐛 问题描述

在尝试现在的服务端数据库的方案时，遇到了好几个坑文档里面都没有提及。需要自己摸索（以及从 repo 里搜到相关的其他人的问题)才能解决。

1. 现有文档中貌似没有提到过，切换成服务端数据库后会导致原有客户端中的数据同步的数据全部丢失。因为切换成服务端数据库后，各个客户端也都同步切换了，需要登录，找不到原来的同步入口，导致我这几个月来的聊天记录完全失踪。。。
2. 希望文档中能够明确说明 S3 存储对于权限的需求。 文档对这块儿也写的比较粗略，我的部署过程中，一开始只是给了AK/AID 相关的全部读写部分，但是实际上还要开放对于这个桶的匿名读部分（这块儿对于客户端以及 OpenAI 等处理时也需要，一开始我以为咱们的客户端以及程序部分只是用 S3 来存储，对于客户端显示以及向服务端发送都会读取后编码 Base64 进行传输，看来不是这样。。。不开匿名的读，就无法显示也无法识别）。这块儿略有不安全，也请在文档中提及。
3. 现在的方案中似乎对于环境变量的依赖比较混乱，很多意想不到的纠缠。例如：
   3.1 第一次尝试更改部署时，我只是尝试着加入了 Database_url 的环境变量，尚未配置 NEXT_PUBLIC_SERVICE_MODE=server 这个变量。本想着只是依次先把各种变量准备好后再切换成服务端。结果就导致重新部署后实际上已经变成服务端的机制了，看到后台有数据库 migrate 失败的提示。
   3.2 等到我的 S3 等都准备好，进行第二次重新部署，发现都部署好后无法上传图片，上传图片时客户端/浏览器会报错。搜了搜 repo 的 issues 时，发现居然要删除掉原有的 ACCESS_CODE 这个环境变量。。。从字面意义上来看，这个环境变量和这部分功能并无直接关系。 删除环境变量，重新部署，随后一切正常。（不，还有刚才第二点说的权限问题，那个是摸索猜测才搞定）。

总之，感谢团队这次的服务端数据库的更新，但是在文档上还需要一些加强，否则对于像我们不熟悉代码结构的用户来说还是难免会出现各种问题。

📷 复现步骤

No response

🚦 期望结果

完善文档。

📝 补充信息

No response

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

📦 Deployment environment

Vercel

📌 Software version

1.1.6

💻 System environment

macOS

🌐 Browser

Edge

🐛 Problem description

When trying the current server-side database solution, I encountered several pitfalls that were not mentioned in the documentation. You need to explore it yourself (and search related problems of other people from the repo) to solve it.

1. It seems that there is no mention in the existing documents that switching to a server-side database will cause all the data synchronized in the original client to be lost. Because after switching to the server database, all clients were also switched simultaneously, requiring login, and the original synchronization entrance could not be found, resulting in the complete disappearance of my chat records in the past few months. . .
2. I hope the documentation can clearly state the permission requirements for S3 storage. The document is also relatively rough on this. During my deployment process, I only gave all the read and write parts related to AK/AID at the beginning, but in fact, I also opened the anonymous read part of this bucket (this part is for It is also needed for client and OpenAI processing. At first, I thought that our client and program parts are only stored in S3. For client display and sending to the server, they will be read and encoded in Base64 for transmission. It seems that this is not the case. . .If anonymous reading is not enabled, it cannot be displayed or recognized). This is slightly unsafe, please mention it in the documentation.
3. The current solution seems to have a confusing dependence on environment variables, with many unexpected entanglements. For example:
   3.1 When I tried to change the deployment for the first time, I just tried to add the environment variable of Database_url, and the variable NEXT_PUBLIC_SERVICE_MODE=server was not configured yet. I originally thought I would just prepare the various variables in sequence and then switch to the server. As a result, after redeployment, it has actually become a server-side mechanism, and you can see a prompt that the database migrate failed in the background.
   3.2 After my S3 was ready, I redeployed it for the second time. I found that after everything was deployed, I could not upload images. The client/browser would report an error when uploading images. When I searched the issues of the repo, I found that the original ACCESS_CODE environment variable should be deleted. . . From a literal sense, this environment variable has no direct relationship with this part of the function. Removed environment variables, redeployed and everything worked fine. (No, there is also the permission issue mentioned in the second point just now, which was solved by guessing).

In short, thank you to the team for this update of the server database, but the documentation still needs some improvement, otherwise various problems will inevitably arise for users like us who are not familiar with the code structure.

📷 Steps to reproduce

No response

🚦 Expected results

Improve documentation.

📝 Supplementary information

No response

[lobehubbot]

👀 @breakstring

Thank you for raising an issue. We will investigate into the matter and get back to you as soon as possible.
Please make sure you have given us as much context as possible.
非常感谢您提交 issue。我们会尽快调查此事，并尽快回复您。 请确保您已经提供了尽可能多的背景信息。

[arvinxx]

1. 去掉服务端环境变量，还会回来的，可以试一下。另外文档开头已经提示了要存备份，你没有看到吗？
2. 这个权限和不同s3服务有关系吧，没法给详细文档，比如 R2 就没有这个配置，或者你可以 PR 一下你用的服务的说明？

3.1. 这一点你不完全按照文档指示，自己瞎搞为啥还要赖文档没写清楚… 如果没用，为啥我要把这个变量写上？😅
3.2. 这个应该是 bug ，后续会修一下的

本身服务端数据库就是一个比较复杂的部署方案。我问过好几个玩 self-hosting 的用户，他们甚至觉得现在的文档写的过于详细了。所以目前应该应该没什么需要再修改的。

如果有用户觉得现在这个文档还是过于简略，出了问题不知道该怎么解决，那我还是推荐用我们 hosting 的版本吧，省心一些🥲

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

1. Remove the server environment variable and it will come back. You can try it. In addition, there is a prompt at the beginning of the document to save a backup, didn’t you see it?
2. Is this permission related to different S3 services? I can’t provide detailed documentation. For example, R2 does not have this configuration. Or can you PR explain the description of the service you use?
   3.1. On this point, if you don’t follow the instructions of the document exactly and mess around on your own, why should you rely on the document not being written clearly... If it doesn’t work, why should I write this variable? 😅
   3.2. This should be a bug and will be fixed later.

The server-side database itself is a relatively complex deployment solution. I have asked several users who are playing with self-hosting, and they even think that the current documentation is too detailed. So there should be nothing that needs to be modified at the moment.

If some users feel that the current document is too simple and they don’t know how to solve problems if they arise, then I still recommend using our hosting version to save worry🥲

[breakstring]

1. 去掉服务端环境变量，还会回来的，可以试一下。另外文档开头已经提示了要存备份，你没有看到吗？
2. 这个权限和不同s3服务有关系吧，没法给详细文档，比如 R2 就没有这个配置，或者你可以 PR 一下你用的服务的说明？

3.1. 这一点你不完全按照文档指示，自己瞎搞为啥还要赖文档没写清楚… 如果没用，为啥我要把这个变量写上？😅 3.2. 这个应该是 bug ，后续会修一下的

本身服务端数据库就是一个比较复杂的部署方案。我问过好几个玩 self-hosting 的用户，他们甚至觉得现在的文档写的过于详细了。所以目前应该应该没什么需要再修改的。

如果有用户觉得现在这个文档还是过于简略，出了问题不知道该怎么解决，那我还是推荐用我们 hosting 的版本吧，省心一些🥲

关于第一点。。。懒得再切换了，太折腾。。。
第二点，目前我使用的华为云的 OBS，和阿里云的 OSS 比较类似，他们对于 S3 类存储的权限控制的都很细致。不太清楚 AWS 和 CF 的 S3 存储的权限控制粒度会是怎样。至少在华为OBS 和阿里的 OSS 里面，如果默认的私有库，只开放了对应 AID/AK 的权限，图片能上传，但是 lobe-chat 的客户端以及通过 URL 方式发送到 OpenAI 之类的 AI 端点是无法访问到的，因为私有桶为了安全默认是无法通过 URL 来访问到里面的内容。正如上面所说的，对于我们不了解您这边详细代码的人来说很容易忽略这一点。我就以为你们是完全通过 base64 编码来向外发送以及在客户端展现。
关于 3.1。在文档里面的示例如下：

# Serverless Postgres DB Url
DATABASE_URL=

# 指定 service mode 为 server，否则不会进入服务端数据库
NEXT_PUBLIC_SERVICE_MODE=server

我根本就没有设置 NEXT_PUBLIC_SERVICE_MODE=server 这个变量，部署时实际上就进入了数据库的迁移逻辑。

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

1. Remove the server environment variable and it will come back. You can try it. In addition, there is a prompt at the beginning of the document to save a backup, didn’t you see it?
2. This permission is related to different S3 services. I can’t provide detailed documentation. For example, R2 does not have this configuration. Or can you PR explain the service you use?

3.1. On this point, if you don’t completely follow the instructions in the document and mess around on your own, why should you rely on the document not being clearly written... If it doesn’t work, why should I write this variable? 😅 3.2. This should be a bug and will be fixed later.

The server-side database itself is a relatively complex deployment solution. I have asked several users who are playing with self-hosting, and they even think that the current documentation is too detailed. So there should be nothing that needs to be modified at the moment.

If some users feel that the current document is too simple and they don’t know how to solve problems if they arise, then I still recommend using our hosting version to save worry🥲

Regarding the first point. . . I'm too lazy to switch again, it's too much trouble. . .
The second point is that the OBS of Huawei Cloud that I currently use is similar to the OSS of Alibaba Cloud. They control the permissions of S3 storage very carefully. It’s not quite clear what the granularity of permission control will be for AWS and CF’s S3 storage. At least in Huawei OBS and Alibaba's OSS, if the default private library only opens the permissions corresponding to AID/AK, pictures can be uploaded, but the client of lobe-chat and sending to AI endpoints such as OpenAI through URL are It is inaccessible because the content in the private bucket cannot be accessed through the URL by default for security reasons. As said above, it's easy to miss this for those of us who don't know the detailed code on your side. I thought you were sending it out and displaying it on the client entirely through base64 encoding.
Regarding 3.1. The example in the documentation is as follows:
,,,

Serverless Postgres DB Url

DATABASE_URL=

Specify service mode as server, otherwise the server database will not be entered

NEXT_PUBLIC_SERVICE_MODE=server
,,,
I didn't set the NEXT_PUBLIC_SERVICE_MODE=server variable at all. When deploying, I actually entered the database migration logic.

[arvinxx]

第二点，目前我使用的华为云的 OBS，和阿里云的 OSS 比较类似，他们对于 S3 类存储的权限控制的都很细致。不太清楚 AWS 和 CF 的 S3 存储的权限控制粒度会是怎样。至少在华为OBS 和阿里的 OSS 里面，如果默认的私有库，只开放了对应 AID/AK 的权限，图片能上传，但是 lobe-chat 的客户端以及通过 URL 方式发送到 OpenAI 之类的 AI 端点是无法访问到的，因为私有桶为了安全默认是无法通过 URL 来访问到里面的内容。正如上面所说的，对于我们不了解您这边详细代码的人来说很容易忽略这一点。我就以为你们是完全通过 base64 编码来向外发送以及在客户端展现。

可能这一部分是需要补充说明下。刚看了下文档里关于 S3 图片的使用在这里一笔带过了：

在客户端 db 的情况下是都通过 base64 传输的，但是在服务端 db 模式中是直接传图片 url。其实后者才是 OpenAI 最推荐的方案（文档），可以大大降低请求传输的流量开销，响应速度也会更快。只是之前在没有服务端 db 的情况下，只能用 base64 编码。现在有 server db 了，自然走图片 URL 更好。

我根本就没有设置 NEXT_PUBLIC_SERVICE_MODE=server 这个变量，部署时实际上就进入了数据库的迁移逻辑。

数据库迁移和应用是两个不同的逻辑。数据库迁移就只依赖 DATABASE_URL 的，而且只在构建时执行，这个逻辑没问题。如果你没配置 NEXT_PUBLIC_SERVICE_MODE ，构建出来的应用就还是 client db 的。

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Second point, the OBS of Huawei Cloud that I currently use is similar to the OSS of Alibaba Cloud. They control the permissions of S3 storage very carefully. It’s not quite clear what the granularity of permission control will be for AWS and CF’s S3 storage. At least in Huawei OBS and Alibaba's OSS, if the default private library only opens the permissions corresponding to AID/AK, pictures can be uploaded, but the client of lobe-chat and the AI ​​endpoints such as OpenAI sent through URL are It is inaccessible because the content in the private bucket cannot be accessed through the URL by default for security reasons. As said above, it's easy to miss this for those of us who don't know the detailed code on your side. I thought you were sending it out and displaying it on the client entirely through base64 encoding.

Maybe this part needs additional explanation. The use of S3 images in the document is briefly mentioned here:

In the case of client db, it is transmitted through base64, but in server db mode, the image url is transmitted directly. In fact, the latter is the most recommended solution by OpenAI (Document), which can greatly reduce the traffic overhead of request transmission and improve the response speed. Faster. It’s just that before there was no server db, base64 encoding could only be used. Now that there is a server db, it is naturally better to use the image URL.

I did not set the NEXT_PUBLIC_SERVICE_MODE=server variable at all. When deploying, it actually entered the database migration logic.

Database migration and application are two different logics. Database migration only relies on DATABASE_URL and is only executed at build time. This logic is no problem. If you do not configure NEXT_PUBLIC_SERVICE_MODE, the built application will still be client db.

[utccnu]

1. 去掉服务端环境变量，还会回来的，可以试一下。另外文档开头已经提示了要存备份，你没有看到吗？
2. 这个权限和不同s3服务有关系吧，没法给详细文档，比如 R2 就没有这个配置，或者你可以 PR 一下你用的服务的说明？

3.1. 这一点你不完全按照文档指示，自己瞎搞为啥还要赖文档没写清楚… 如果没用，为啥我要把这个变量写上？😅 3.2. 这个应该是 bug ，后续会修一下的

本身服务端数据库就是一个比较复杂的部署方案。我问过好几个玩 self-hosting 的用户，他们甚至觉得现在的文档写的过于详细了。所以目前应该应该没什么需要再修改的。

如果有用户觉得现在这个文档还是过于简略，出了问题不知道该怎么解决，那我还是推荐用我们 hosting 的版本吧，省心一些🥲

感觉目前文档确实有点 conflicted. 我昨晚刚从 0.x 操作升级到 1.x 的有服务端 persistence 的配置。
SSO 部分比较顺滑，得益于确实配置非常简洁；但 DB 部分。。至今也没搞定持久化。

文档的一些问题：

1. 环境变量几个地方不统一。ENABLE_OAUTH_SSO 在某页说必填，但实际上没有也行。NEXT_AUTH_SSO_PROVIDERS 在 环境变量部分的汇总说明提示可以有多个，但是之前的独立配置没提。https://lobehub.com/zh/docs/self-hosting/environment-variables 这个汇总说明里，没有提数据库部分。至少我对文档的阅读习惯，由于我 docker compose 部署的，我是上来就先看这页的，但一头雾水。另外印象中还有某页把 NEXT_AUTH_SECRET 写成了 NEXTAUTH_SECRET? 忘了，反正昨晚就是一团混乱，最后还是通过 docker logs 看启动日志里提到有一些变量 deprecated, 然后改过来
2. 关于数据库部分，我觉得我似乎是配置了，但没有生效。。但 docker logs 也没说到底用没用 server side pg db. 我现在是不急用，否则真是要心急如焚呀
   KEY_VAULTS_SECRET=
   DATABASE_URL=
   DATABASE_DRIVER=node
   NEXT_PUBLIC_SERVICE_MODE=serve
   这几项都正确配置了，跨浏览器登录，对话还是没同步。

至于 ACCESS_CODE 还要不要，现在也不明白。。

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

1. Remove the server environment variable and it will come back. You can try it. In addition, there is a prompt at the beginning of the document to save a backup, didn’t you see it?
2. This permission is related to different S3 services. I can’t provide detailed documentation. For example, R2 does not have this configuration. Or can you PR explain the service you use?

3.1. On this point, if you don’t completely follow the instructions in the document and mess around on your own, why should you rely on the document not being clearly written... If it doesn’t work, why should I write this variable? 😅 3.2. This should be a bug and will be fixed later.

The server-side database itself is a relatively complex deployment solution. I have asked several users who are playing with self-hosting, and they even think that the current documentation is too detailed. So there should be nothing that needs to be modified at the moment.

If some users feel that the current document is too simple and they don’t know how to solve problems if they arise, then I still recommend using our hosting version to save worry🥲

I feel that the current documentation is indeed a bit conflicted. I just upgraded from 0.x operation to 1.x configuration with server persistence last night.
The SSO part is relatively smooth, thanks to the very simple configuration; but the DB part. . So far, persistence has not been achieved.

Some issues with the documentation:

1. The environment variables are not consistent in several places. ENABLE_OAUTH_SSO says it is required on a certain page, but in fact it doesn’t matter. The summary description of NEXT_AUTH_SSO_PROVIDERS in the `Environment Variables' section suggests that there can be multiple, but the previous independent configuration did not mention it. https://lobehub.com/zh/docs/self-hosting/environment-variables This summary description does not mention the database part. At least my habit of reading documents, because I deployed docker compose, I read this page first when I came up, but I was confused. In addition, I remember that there is a page where NEXT_AUTH_SECRET was written as NEXTAUTH_SECRET? I forgot, anyway, last night was a mess. Finally, I checked the startup log through docker logs and mentioned that some variables were deprecated, and then changed them.
2. Regarding the database part, I think I have configured it, but it has not taken effect. . But I don’t know whether docker logs is useful or not. Server side pg db. I am not in a hurry to use it now, otherwise I will be really anxious.
   KEY_VAULTS_SECRET=
   DATABASE_URL=
   DATABASE_DRIVER=node
   NEXT_PUBLIC_SERVICE_MODE=serve
   These items are configured correctly, and even though I log in across browsers, the conversations are still out of sync.

As for whether ACCESS_CODE is still needed, I don’t know yet. .

[ZeroDeng01]

1. 去掉服务端环境变量，还会回来的，可以试一下。另外文档开头已经提示了要存备份，你没有看到吗？

2. 这个权限和不同s3服务有关系吧，没法给详细文档，比如 R2 就没有这个配置，或者你可以 PR 一下你用的服务的说明？

3.1. 这一点你不完全按照文档指示，自己瞎搞为啥还要赖文档没写清楚… 如果没用，为啥我要把这个变量写上？😅 3.2. 这个应该是 bug ，后续会修一下的

本身服务端数据库就是一个比较复杂的部署方案。我问过好几个玩 self-hosting 的用户，他们甚至觉得现在的文档写的过于详细了。所以目前应该应该没什么需要再修改的。

如果有用户觉得现在这个文档还是过于简略，出了问题不知道该怎么解决，那我还是推荐用我们 hosting 的版本吧，省心一些🥲

感觉目前文档确实有点 conflicted. 我昨晚刚从 0.x 操作升级到 1.x 的有服务端 persistence 的配置。

SSO 部分比较顺滑，得益于确实配置非常简洁；但 DB 部分。。至今也没搞定持久化。

文档的一些问题：

1. 环境变量几个地方不统一。ENABLE_OAUTH_SSO 在某页说必填，但实际上没有也行。NEXT_AUTH_SSO_PROVIDERS 在 环境变量部分的汇总说明提示可以有多个，但是之前的独立配置没提。https://lobehub.com/zh/docs/self-hosting/environment-variables 这个汇总说明里，没有提数据库部分。至少我对文档的阅读习惯，由于我 docker compose 部署的，我是上来就先看这页的，但一头雾水。另外印象中还有某页把 NEXT_AUTH_SECRET 写成了 NEXTAUTH_SECRET? 忘了，反正昨晚就是一团混乱，最后还是通过 docker logs 看启动日志里提到有一些变量 deprecated, 然后改过来

2. 关于数据库部分，我觉得我似乎是配置了，但没有生效。。但 docker logs 也没说到底用没用 server side pg db. 我现在是不急用，否则真是要心急如焚呀

KEY_VAULTS_SECRET=

DATABASE_URL=

DATABASE_DRIVER=node

NEXT_PUBLIC_SERVICE_MODE=serve

这几项都正确配置了，跨浏览器登录，对话还是没同步。

至于 ACCESS_CODE 还要不要，现在也不明白。。

docker部署需要自己修改dockerfile然后build，官方目前的docker镜像由于next环境变量和构建问题不支持db版

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

1. Remove the server environment variable and it will come back. You can try it. In addition, there is a prompt at the beginning of the document to save a backup, didn’t you see it?

2. Is this permission related to different S3 services? I can’t provide detailed documentation. For example, R2 does not have this configuration. Or can you PR explain the description of the service you use?

3.1. On this point, if you don't follow the instructions of the document exactly and mess around on your own, why should you rely on the document not being written clearly... If it doesn't work, why should I write this variable? 😅 3.2. This should be a bug and will be fixed later.

The server-side database itself is a relatively complex deployment solution. I have asked several users who are playing with self-hosting, and they even think that the current documentation is too detailed. So there should be nothing that needs to be modified at the moment.

If some users feel that the current document is too simple and they don’t know how to solve problems if they arise, then I still recommend using our hosting version to save worry🥲

I feel that the current documentation is indeed a bit conflicted. I just upgraded from 0.x to 1.x last night with server-side persistence configuration.

The SSO part is relatively smooth, thanks to the very simple configuration; but the DB part. . So far, persistence has not been achieved.

Some issues with the documentation:

1. The environment variables are not consistent in several places. ENABLE_OAUTH_SSO says it is required on a certain page, but in fact it doesn’t matter. The summary description of NEXT_AUTH_SSO_PROVIDERS in the `Environment Variables' section suggests that there can be multiple, but the previous independent configuration did not mention it. https://lobehub.com/zh/docs/self-hosting/environment-variables This summary description does not mention the database part. At least my habit of reading documents, because I deployed docker compose, I read this page first when I came up, but I was confused. In addition, I remember that there is a page where NEXT_AUTH_SECRET was written as NEXTAUTH_SECRET? I forgot, anyway, last night was a mess. Finally, I checked the startup log through docker logs and mentioned that some variables were deprecated, and then changed them.

2. Regarding the database part, I think I have configured it, but it does not take effect. . But I don’t know whether docker logs is useful or not. Server side pg db. I am not in a hurry to use it now, otherwise I will be really anxious.

KEY_VAULTS_SECRET=

DATABASE_URL=

DATABASE_DRIVER=node

NEXT_PUBLIC_SERVICE_MODE=serve

These items are configured correctly, but the conversations are still out of sync when logged in across browsers.

As for whether ACCESS_CODE is still needed, I don’t know yet. .

Docker deployment requires you to modify the dockerfile and then build it. The official current docker image does not support the db version due to next environment variables and build issues.

[utccnu]

1. 去掉服务端环境变量，还会回来的，可以试一下。另外文档开头已经提示了要存备份，你没有看到吗？

2. 这个权限和不同s3服务有关系吧，没法给详细文档，比如 R2 就没有这个配置，或者你可以 PR 一下你用的服务的说明？

3.1. 这一点你不完全按照文档指示，自己瞎搞为啥还要赖文档没写清楚… 如果没用，为啥我要把这个变量写上？😅 3.2. 这个应该是 bug ，后续会修一下的

本身服务端数据库就是一个比较复杂的部署方案。我问过好几个玩 self-hosting 的用户，他们甚至觉得现在的文档写的过于详细了。所以目前应该应该没什么需要再修改的。

如果有用户觉得现在这个文档还是过于简略，出了问题不知道该怎么解决，那我还是推荐用我们 hosting 的版本吧，省心一些🥲

感觉目前文档确实有点 conflicted. 我昨晚刚从 0.x 操作升级到 1.x 的有服务端 persistence 的配置。
SSO 部分比较顺滑，得益于确实配置非常简洁；但 DB 部分。。至今也没搞定持久化。
文档的一些问题：

1. 环境变量几个地方不统一。ENABLE_OAUTH_SSO 在某页说必填，但实际上没有也行。NEXT_AUTH_SSO_PROVIDERS 在 环境变量部分的汇总说明提示可以有多个，但是之前的独立配置没提。https://lobehub.com/zh/docs/self-hosting/environment-variables 这个汇总说明里，没有提数据库部分。至少我对文档的阅读习惯，由于我 docker compose 部署的，我是上来就先看这页的，但一头雾水。另外印象中还有某页把 NEXT_AUTH_SECRET 写成了 NEXTAUTH_SECRET? 忘了，反正昨晚就是一团混乱，最后还是通过 docker logs 看启动日志里提到有一些变量 deprecated, 然后改过来
2. 关于数据库部分，我觉得我似乎是配置了，但没有生效。。但 docker logs 也没说到底用没用 server side pg db. 我现在是不急用，否则真是要心急如焚呀

KEY_VAULTS_SECRET=
DATABASE_URL=
DATABASE_DRIVER=node
NEXT_PUBLIC_SERVICE_MODE=serve
这几项都正确配置了，跨浏览器登录，对话还是没同步。
至于 ACCESS_CODE 还要不要，现在也不明白。。

docker部署需要自己修改dockerfile然后build，官方目前的docker镜像由于next环境变量和构建问题不支持db版

是吧... 对我来说，有点失望但也无所谓，我不急，就自己用而已。但文档是不是没提？或者这个 "env variables and build issues" 要咋解决？

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

1. Remove the server environment variable, it will come back, you can try it. In addition, there is a prompt at the beginning of the document to save a backup, didn’t you see it?

2. Is this permission related to different s3 services? I can’t provide detailed documentation. For example, R2 does not have this configuration. Or can you PR explain the description of the service you use?

3.1. On this point, if you don’t follow the documentation instructions exactly and mess around on your own, why should you rely on the documentation not being written clearly... If it doesn’t work, why should I write this variable? 😅 3.2. This should be a bug and will be fixed later.

The server-side database itself is a relatively complex deployment solution. I have asked several users who are playing with self-hosting, and they even think that the current documentation is too detailed. So there should be nothing that needs to be modified at the moment.

If some users feel that this document is still too simple and they don’t know how to solve problems if they arise, then I still recommend using our hosting version, which will save you some worry🥲

It feels like the current documentation is indeed a bit conflicted. I just upgraded from 0.x to 1.x last night with server-side persistence configuration.
The SSO part is relatively smooth, thanks to the very simple configuration; but the DB part. . So far, persistence has not been achieved.
Some issues with the documentation:

1. The environment variables are not consistent in several places. ENABLE_OAUTH_SSO says it is required on a certain page, but in fact it doesn’t matter. The summary description of NEXT_AUTH_SSO_PROVIDERS in the `Environment Variables' section suggests that there can be multiple, but the previous independent configuration did not mention it. https://lobehub.com/zh/docs/self-hosting/environment-variables This summary description does not mention the database part. At least my habit of reading documents, because I deployed docker compose, I read this page first when I came up, but I was confused. In addition, I remember that there is a page where NEXT_AUTH_SECRET was written as NEXTAUTH_SECRET? I forgot, anyway, last night was a mess. Finally, I checked the startup log through docker logs and mentioned that some variables were deprecated, and then changed them.
2. Regarding the database part, I think I have configured it, but it does not take effect. . But I don’t know whether docker logs is useful or not. Server side pg db. I am not in a hurry to use it now, otherwise I will be really anxious.

KEY_VAULTS_SECRET=
DATABASE_URL=
DATABASE_DRIVER=node
NEXT_PUBLIC_SERVICE_MODE=serve
These items are configured correctly, and the conversations are still out of sync when logged in across browsers.
As for whether ACCESS_CODE is still needed, I don’t know yet. .

Docker deployment requires you to modify the dockerfile and then build it. The official current docker image does not support the db version due to next environment variables and build issues.

Right... For me, it's a bit disappointing but it doesn't matter. I'm not in a hurry, I just use it for myself. But does the document not mention it? Or how to solve this "env variables and build issues"?

[arvinxx]

文档是不是没提

文档开头就说了不支持 Docker ，你是没看到么…

[cy948]

@utccnu 我最近也构建不成功，直接 heap out of memory 了

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

@utccnu I also failed to build recently and it directly heap out of memory.

[cy948]

我最近也构建不成功，直接 heap out of memory 了

刚在自己电脑上build成功了，用时6分钟。🫠

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

My recent build failed and the heap was out of memory.

I just built it successfully on my computer and it took 6 minutes. 🫠

[utccnu]

我最近也构建不成功，直接 heap out of memory 了

刚在自己电脑上build成功了，用时6分钟。🫠

我在 m1 pro 上也几分钟完成了。。但没法用，跑起来就出错，还是说找不到 SECRET 啥的，但实际上 env 已经设置了。算了算了放弃了。。等你啊！

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

My recent build failed and the heap was out of memory.

I just built it successfully on my computer and it took 6 minutes. 🫠

I also did it in a few minutes on my m1 pro. . But it doesn't work. It gives an error when running. It still says that SECRET cannot be found, but in fact env has been set. Forget it, give up. . Wait for you!

[cy948]

@utccnu 不如加入 discord，试试使用 NextAuth 的后端数据库版本。

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

@utccnu Why not join discord and try using the backend database version of NextAuth.

[Sun-drenched]

@utccnu 我最近也构建不成功，直接 heap out of memory 了

构建的话也不一定非要用自己的机器吧，用容器镜像服务就行了。

[lobehubbot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

@utccnu I also failed to build recently, and it directly heap out of memory.

You don’t have to use your own machine to build, just use a container image service.

[scrpr]

使用Node Postgres的时候，还需要注意自签名证书的问题
部分Postgres服务商使用自签名的CA证书，比如Aiven

此时如果使用服务方提供的URL的话，就会出现自签名证书问题：

❌ Database migrate failed: Error: self-signed certificate in certificate chain
    at /vercel/path0/node_modules/pg-pool/index.js:45:11
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at PgDialect.migrate (/vercel/path0/node_modules/src/pg-core/dialect.ts:72:3)
    at Object.migrate (/vercel/path0/node_modules/src/neon-serverless/migrator.ts:10:2)
    at runMigrations (/vercel/path0/scripts/migrateServerDB/index.ts:12:3) {
  code: 'SELF_SIGNED_CERT_IN_CHAIN'

原因在于，node-postgres在解析Connection String的时候行为与官方文档不一致。官方文档里sslmode=require的时候，如果本地存在CA证书就检查证书，没有就不检查；

而node-postgres的实现中，多出了官方文档中没有的no-verify，选择此项时则不会验证证书；而prefer、require、verify-ca、verify-full 这4个选项行为完全一致，都是验证所有证书。

早在2年前便已经有人提出了修复pr使行为对齐官方文档，但至今未合并。brianc/node-postgres#2709

太长不看：node-postgres实现跟官方不一致，将URL中的?sslmode=require替换为?sslmode=no-verify即可。

[utccnu]

使用Node Postgres的时候，还需要注意自签名证书的问题 部分Postgres服务商使用自签名的CA证书，比如Aiven

此时如果使用服务方提供的URL的话，就会出现自签名证书问题：

❌ Database migrate failed: Error: self-signed certificate in certificate chain
    at /vercel/path0/node_modules/pg-pool/index.js:45:11
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at PgDialect.migrate (/vercel/path0/node_modules/src/pg-core/dialect.ts:72:3)
    at Object.migrate (/vercel/path0/node_modules/src/neon-serverless/migrator.ts:10:2)
    at runMigrations (/vercel/path0/scripts/migrateServerDB/index.ts:12:3) {
  code: 'SELF_SIGNED_CERT_IN_CHAIN'

原因在于，node-postgres在解析Connection String的时候行为与官方文档不一致。官方文档里sslmode=require的时候，如果本地存在CA证书就检查证书，没有就不检查； 而node-postgres的实现中，多出了官方文档中没有的no-verify，选择此项时则不会验证证书；而prefer、require、verify-ca、verify-full 这4个选项行为完全一致，都是验证所有证书。

早在2年前便已经有人提出了修复pr使行为对齐官方文档，但至今未合并。brianc/node-postgres#2709

太长不看：node-postgres实现跟官方不一致，将URL中的?sslmode=require替换为?sslmode=no-verify即可。

我昨天用 heroku 也不成功，开始也以为是证书问题，刚改成了 no-verify 还是错误，仔细看 log 是这样

这个 pg url 我在本机用 python 是可以连上的。。不熟悉 pg, 怎么冒出来个 wss:// 链接，而且尝试 443 去了

[utccnu]

使用Node Postgres的时候，还需要注意自签名证书的问题 部分Postgres服务商使用自签名的CA证书，比如Aiven

此时如果使用服务方提供的URL的话，就会出现自签名证书问题：

❌ Database migrate failed: Error: self-signed certificate in certificate chain
    at /vercel/path0/node_modules/pg-pool/index.js:45:11
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at PgDialect.migrate (/vercel/path0/node_modules/src/pg-core/dialect.ts:72:3)
    at Object.migrate (/vercel/path0/node_modules/src/neon-serverless/migrator.ts:10:2)
    at runMigrations (/vercel/path0/scripts/migrateServerDB/index.ts:12:3) {
  code: 'SELF_SIGNED_CERT_IN_CHAIN'

原因在于，node-postgres在解析Connection String的时候行为与官方文档不一致。官方文档里sslmode=require的时候，如果本地存在CA证书就检查证书，没有就不检查； 而node-postgres的实现中，多出了官方文档中没有的no-verify，选择此项时则不会验证证书；而prefer、require、verify-ca、verify-full 这4个选项行为完全一致，都是验证所有证书。

早在2年前便已经有人提出了修复pr使行为对齐官方文档，但至今未合并。brianc/node-postgres#2709

太长不看：node-postgres实现跟官方不一致，将URL中的?sslmode=require替换为?sslmode=no-verify即可。

刚才我也试了 aiven, 同样是我上面提到的 443 访问错误。。你 aiven build 能通过？

[scrpr]

使用Node Postgres的时候，还需要注意自签名证书的问题 部分Postgres服务商使用自签名的CA证书，比如Aiven
此时如果使用服务方提供的URL的话，就会出现自签名证书问题：

❌ Database migrate failed: Error: self-signed certificate in certificate chain
    at /vercel/path0/node_modules/pg-pool/index.js:45:11
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at PgDialect.migrate (/vercel/path0/node_modules/src/pg-core/dialect.ts:72:3)
    at Object.migrate (/vercel/path0/node_modules/src/neon-serverless/migrator.ts:10:2)
    at runMigrations (/vercel/path0/scripts/migrateServerDB/index.ts:12:3) {
  code: 'SELF_SIGNED_CERT_IN_CHAIN'

原因在于，node-postgres在解析Connection String的时候行为与官方文档不一致。官方文档里sslmode=require的时候，如果本地存在CA证书就检查证书，没有就不检查； 而node-postgres的实现中，多出了官方文档中没有的no-verify，选择此项时则不会验证证书；而prefer、require、verify-ca、verify-full 这4个选项行为完全一致，都是验证所有证书。
早在2年前便已经有人提出了修复pr使行为对齐官方文档，但至今未合并。brianc/node-postgres#2709
太长不看：node-postgres实现跟官方不一致，将URL中的?sslmode=require替换为?sslmode=no-verify即可。

刚才我也试了 aiven, 同样是我上面提到的 443 访问错误。。你 aiven build 能通过？

非serverless的postgres实例需要添加环境变量更改driver，参见官方文档（现在访问不了服务端数据库的页面？）

  # 指定 Postgres database driver 为 node
  DATABASE_DRIVER=node

[arvinxx]

https://lobehub.com/docs/self-hosting/server-database 目前初步调整完毕服务端数据库的部署文档框架，相关内容正在陆续补充中。有任何问题欢迎在 #3391 回复