Show HN: I am building an open-source Confluence and Notion alternative (github.com)
Hello HN,
I am building Docmost, an open-source collaborative wiki and documentation software. It is an open-source alternative to Confluence and Notion.
I have been working on it for the past 12 months. This is the first public release (beta).
The rich-text editor has support for real-time collaboration, LaTex, inline comments, tables, and callouts to name a few.
Features
- Collaborative real-time editor
- Spaces (Teamspace)
- User permissions
- Groups
- Comments
- Page history
- Nested pages
- Search
- File attachments
You can find screenshots of the product on the website.
Website: https://docmost.com
Github: https://github.com/docmost/docmost
Documentation: https://docmost.com/docs
I would love to hear your feedback.
Thank you.
221 comments
[ 2.9 ms ] story [ 165 ms ] threadKnowledge management is a special area. Look forward to seeing this grow.
As a heavy user of both Confluence and Notion, and in the interest in seeing alternatives like this grow:
Is there any plan to make this tool local/offline-first and mobile-first? There's a big need in this feature, and something that's best baked into the bread early. It's a big gap of Notion and ultimately why I had to ditch it.
Confluence has some ways to at least cache enough of it, or use a plugin. Confluence is also massive, lots of features (including workflows and approvals).. it might be worth clarifying which ones you're covering and planning to cover.
Thanks!
On to the option -- currently been giving Anytype a pretty hard go on the colalboration side, as well as playing with Obsidian to see if it can feed into it.
https://anytype.io/
Mobile-first? If you are referring to mobile apps, it will probably come in the future.
For now, it’s just me building. I am focusing more on building the core features of a wiki.
Thank you for your positive words. I appreciate it.
This is something I’m going to keep a close eye on. My company is using confluence and I hate how slow confluence is.
Your marketing site, the menu doesn’t close when clicking on an item on mobile Firefox on IOS
I bring this up because a feature that could set you apart from others is the concept of a “merge request” for documentation. Where someone can make a document, another can modify it and submit changes for review.
GitBook has this but it lacks in some other key ways for us.
I dont want a different system handling edits reviews and merges.
I just want CD to send my docs from git to a system that can properly host / give me the Doc-related features I need.
Being markdown centric would be great. Makes this tool a great destination for so much markdown content already existing.
Material for Mkdocs does exactly this.
https://squidfunk.github.io/mkdocs-material/
On docmost.com, pinch to zoom is disabled when viewing screenshots (Firefox Android).
Unfortunately, there is no public demo yet. If you email me (in bio), I can create a demo for you.
I got it running in Docker. I had to run "docker-compose up -d" rather than the instructions' "docker compose up -d" (no dash), which just gave a confusing error message about not knowing "-d".
It looks great!
I got confused at first between Workspaces and Spaces. It seems that Workspaces contain Spaces which contain Pages? I like that, but the names seem too similar.
I noticed the page title doesn't update on some locations. E.g. I go into a page, the title updates, but then when I leave the note the title remains. Similarly the "Login" title persisted after I'd logged in.
It took me a minute to figure out how to access it from other computers on my local network, and the problem was I left the APP_URL as localhost. Confusingly, that partly worked, so it might be worth putting in a warning about it. With APP_URL set to localhost, if on another computer on the same network I go to <ip address>:3000, it redirects to <ip address>:3000/home, so something is connecting, but then nothing loads and it's just a blank screen (there's an error message in the browser console about failing to load resources from "localhost").
How and where are pages stored? I would love to use this, but need robust backup/restore.
Edit: It would be great if going to a page URL when not logged in would redirect to that page after login.
Edit 2: "Copy link" doesn't work? It pops up a message saying "Link copied" but it's not in the clipboard.
2. Your understanding of the hierarchy is correct. Workspace -> Space -> Page. I admit, the naming is similar and can be confusing. I just couldn't come up with a conclusive alternative while self-debating it. Do you have better suggestions?
3. I will look into the title issue. Thanks for pointing out.
4. I will put the APP_URL thing in mind too.
5. The pages are stored in the pages table. The content is stored in 3 formats, i. Prosemirror Json (default editor state). ii. Yjs state (real-time collaboration). iii. raw Text (for search indexing). The affected tables are json_content, ydoc and text_content
5. I will look into the redirect issue, and "Copy link" bug.
I appreciate your feedback and thank you for trying it out.
2. I think something like Project would work better than Space.
4. Does the app need to know its server name? Can it just use relative URLs everywhere instead of absolute? That would simplify configuration.
5. Thanks, I've had a poke around in the DB. I think a Backup/Restore feature in the UI is important. Also good would be a way to request the data programmatically e.g. I'd put it in a cron job before my Borg backup job runs (that would store daily versions using diffs, so it would need to be uncompressed). An "export to HTML/Markdown/[something importable]" feature would help people feel comfortable trusting the app. I have thousands of pages of handwritten notes in an Android app called Squid, and regularly export from that to back it up (it gives me an SQLite DB file only readable by Squid, which is okay but not ideal); without that backup option I'd be pretty worried about losing my work in there, and I get the same feeling about Docmost.
By the way, are you allowed to distribute the Tiptap Pro extensions? E.g. the Latex support and Comments.
2. With a small change, I can make the frontend use the window.location URL if none is set. On the backend, the catch is emails. Emails with link use the APP_URL to build it.
3. I do not really think "backup" belongs to the UI, but there is a possibility. I plan to work on HTML and Markdown exports. We have what it takes already from the editor.
3. Latex and Comments do not use the Tiptap Pro extensions, so it's fine. Also, the comment extension is entirely different from Tiptap's own which depends on Tiptap Cloud to work.
1. Everything is locked in. I want to be able to easily export or back up my notes.
2. The pricing is so nickel and dimey. Have more than 100 nodes in the document tree? Upgrade your tier. Adding new people to projects is a buying decision every time and it’s fatiguing.
Can you tell us more about how it uses pg and redis?
Redis is used for queues, collaborative editor state sync across servers, and WebSocket sync across servers. The last two functions are important when running the software on multiple nodes or replicas.
What was the thought process for AGPL instead of something else ?
AGPL is useful also for preventing commercial improvements that don't make it back into the general product.
All free software licenses are open source licenses.
The original comment was:
> AGPL is excellent for promoting the spirit of open source
This statement is not about the practical compatibility of the license, this is a statement about what the license stands for. The license categorically does not stand for Open Source.
I will admit that it would be very cool to see a client that abstracted got and markdown away for non-technical users.
I feel like obsidian with some more git polish could get it done.
Probably runs on phones better.
Note how I said that git and markdown could be abstracted away, as in hidden from the user who can’t be bothered to learn. Use them under the hood, so at the end of the day your entire wiki is just a repo.
Both Nextcloud and XWiki do this.
Now, why not git+markdown? I'm not sure it exists so we can't really know if it can work well or not.
I have my doubts:
About Markdown: I believe it is fine for very basic content, but you will probably want something more powerful to cover more advanced needs. HTML will be too low level for this, so you will probably need something to extend Markdown with custom macros, at which point you may as well adopt something that already exists.
For git: wikis tend to have versioning per document, not of the whole stuff. You will want to have easy and efficient document history manipulation (access of old revisions, comparison between revision, rollback). And you may want the wiki to remain efficient with a large number of documents and revisions, even when multiple people are writing to the wiki at the same time, and the git repository might be a bottleneck.
For a single user with simple note taking needs, I believe git+markdown can have good characteristics. I'm not sold on the git+markdown thing for a multi user wiki. It would need to be proven, but should someone do this, they should not solve "How do I write wiki software based on git+markdown", the problem should be "I need to have a wiki that's efficient in such and such cases, and git+markdown is a good basis because [...]".
Me and my partner currently use Apple Notes for this, simple stuff like grocery lists, todo lists, etc. But Apple Notes perf is abysmal with real-time collab. The app constantly hangs and fans are spinning non-stop. iOS is not much better.
Async collaboration happens with git, synchronous can happen with any text editor that supports collaborative editing.
Lots of companies are technically exposed to the risks related to this kind of thing, could be legitimately sued. But they don’t always recognize this aspect of their exposure.
It seems natural to me that this sort of thing will become more important over time.
More interesting to me though is what prompted your question. Parent requested making things accessible because that’s something as individual they need and benefit from. It wasn’t about how important it might be to “companies”. Individual people need accessibility.
I don’t like Atlassian products very much for a lot of reasons (each iteration of the UI gets worse), but the login process has never been an issue for me, so I’m surprised to see your comment.
Absolutely psychopatic behaviour.
And that's just for people with typical hands and eyes.
Imagine of what it's like for people with disabilities.
My exerience with automated tools has been less than stellar. Oh, an image has an alt tag? Congrats, it's accessible, even if that alt tag literally just says "alt tag". I also don't think "simply turn on accessibility features yourself" is a proper solution. It feels like there's a massive difference between me using such tools for the the purpose of testing one website and someone actually relying on such tools.
Source: I've been part of an accessibility taskforce at my company for a long time.
[1] https://linuxafterdark.net/linux-after-dark-episode-72/ [2] https://florianbeijers.xyz/
The experience was also humbling in an awesome way. I think I still haven't seen anyone navigate the web as fast as this one blind person was capable of, due to the mastery of his tools.
Had the same feeling now three times while watching vision, impaired people using accessibility tools. They can absolutely fly through things much faster than a typical user can. Aside from the general awesomeness that is taking something that most people would consider a disability and turning it into a superpower, it makes me think that I am really missing something by not having that skill.
Has anybody done this before and can offer some advice for how to start, and where to go with it? I am a Linux-only user, which I assume is going to matter for the tooling.
Heh, I guess you are in fact a VI-sion impaired person flying through things when using these editors.
Meta comment, but this made me smile. I love the vivid expression, the raw humility, and the philosophically deep but humorous and light hearted commentary on how it feels to have your code evaluated :-)
I'd say for smaller teams it is doubly important to think about this topic early to minimize the overhead of having to fix a whole bunch of bad moves you figure out you've made when someone complains months or even years after you've made them. As for doing this now and again, I think some of the QA firms like APplause and such do offer accessibility testing services and such now, and there's social media like HN, Reddit, Mastodon or, if one must, X, where people can be found who'll be happy to do this provided they can be fairly compensated. Not exactly structural or centraalized but there you have it :)
I'm sitting on a codebase with ~20 HTML ARIA warnings from SvelteKit's lint and frankly don't expect to get to fix them any time soon. I'd like to, but there's always something else to put the effort into. And that's when the framework is trying to nudge me in the correct direction, not active effort!
[1]: So, frankly, not that much: https://www.npr.org/sections/krulwich/2011/12/21/144066248/l...
Which tools did you use? I’d argue a human probably also won’t review all your alt tags manually or you could just do it yourself, too. If you have lots of them it might make sense to extract them automatically and pipe them to some language model to generate a score for each of them. Then you can review the ones with the worst scores.
It seems to me that https://wave.webaim.org/ does a good job with ensuring contrast is good, etc., as once I followed all the recommendations things are also readable when using Dev Tools to simulate various vision deficiencies.
Usability: This button is hard to understand and/or confusing to operate.
Accessibility: I cannot operate the button AT ALL, cannot perceive it, or can only do so using advanced assistive technology tricks.
- Wayland didn't think it was important to immediately include this, and now we have the majority of linux distributions having serious issues with screenreaders and other assistive tech. Fedora's shipped with this broken for almsot a decade. Calamares didn't think it'd be important to fix and has been broken for about as long. - Particularly now, with devs grabbing a component library on top of React with a generous helping of CSS frameworks and third-party NPM-based extra bits that are all tangled together, and what have you, if you don't vet this stuff beforehand you'll have to retrofit half your UI to fix things after the fact. That, right there, is why accessibility seems so hard to implement.
Fixing a native HTML select for accessibility is easy; it already is. Fixing some componentized overengineered monstrosity that figured they'd get to it later and as a result doesn't speak with screen readers, doesn't work on phones, doesn't work when zoomed in, doesn't respond to speech recognition software, goes absolutely nuts when the user scrolls, and doesn't let you use it properly with a keyboard... yeah that is harder :)
For example, the sidebar page tree supports keyboard navigation.
The UI library I am using, Mantine, follows accessibility best practices and has full keyboard support.
There is still a lot to do in this regard. As the project progresses, more support will come.
In the past, I built a Twitter bot (@threadvoice) to help people listen to Twitter threads in audio format ( https://twitter.com/Philipofficial9/status/11899711858004869... ). I had accessibility as one of my motivations while building it.
I use PlantUML extensively and tools like Znai and others have native support for it.
Even being able to embed something like diagrams.net right into the page via plugin for the time being (and save the resulting file in the system) would be great.
I chose Node mainly because of Yjs, which powers the real-time collaborative editing.
Docmost uses Hocuspocus (by Tiptap) as the websocket backend for Yjs (https://tiptap.dev/docs/hocuspocus/introduction).
Note: Outline is another Open-Source Documentation/Wiki and Collaboration tooling option I like.
https://www.getoutline.com
https://github.com/outline
Outline is a great software, I have tried it.
You do not want to run this in Postgres, or any RDBMS for that matter. I promise you. Here [0] is `y-sweet` [1] discussing (at a shallow level) why persisting the actual content in an RDBMS isn't great. At $COMPANY, we ran Postgres on massive EC2s with native NVMe drives for storage, and they still struggled with this stuff (albeit with the rest of the app also using them). Use an object store, use an LSM-tree solution like MyRocks [2], just don't use an RDBMS, and especially not Postgres. It is uniquely bad at this. I'll explain.
Let's say I'm storing RFC2324 [3]. In TXT format, this is just shy of 20 KB. Even if it's 1/5th that size, it doesn't matter for the purposes of this discussion. As you may or may not know, Postgres uses something called TOAST [4] for storing large amounts of data (by default, any time a tuple hits 2 KB). This is great, except there's an overhead to de-TOAST things. This overhead can add up on retrievals.
Then there's WAL amplification. Postgres doesn't really do an `UPDATE`, it does a `DELETE` + `INSERT`. Even worse, it has to write entire pages (8 KB) [5], not just the changed content (there are circumstances in which this isn't true, but assume it is in general). Here's a view of `pg_stat_wal`, after I've been playing with it:
Now I'll change a single byte in the aforementioned RFC, and run that again: That is nearly 120 KB of WAL written to change one byte. This is of course dependent upon the size of the document being edited, but it's always going to be bad.Now let's look at the search query [6], which I've reproduced (mostly; I left out creator_id and the ORDER BY) here:
~50 msec to do a relatively simple SELECT with no JOINs isn't great, and it's from the use of `ts_headline`. Unfortunately, it has to parse the original document, not just the tsvector summary to produce results. If I remove that function from the query, it plummets to sub-msec times, as I would expect.It doesn't get better if I forcibly disable sequential scans to get it to favor the GIN index on `tsv` (unsurprising, given the small dataset):
However, do you think an application like this would be database bound? It feels like so many more things would limit throughout (and product market fit) before Postgres.
Given its buried a bit in their stack, they can always optimize later as well.
Re: optimize it later, your persistence model is the hardest thing to change once it’s built and full of data. I strongly recommend getting that right the first time.
Confluence itself uses relational databases including Postgres, and they seem to do well too.
And I know for a fact that both handle huge wikis. (hundreds of spaces, millions of document revisions)
You can store essentially anything in an RDBMS, especially Postgres. That doesn’t make it the right choice. It might make it easier, but easier isn’t the same thing as correct.
I am of course biased as a DBRE, since I’m the one who gets paged about problems caused by decisions like this. Then I get to deliver the uncomfortable news that everything needs to be overhauled, and inevitably am told that’s not going to happen, and to just figure it out.
Indeed, the Yjs state update can be problematic due to its growing size and constant updates.
I will have a look at MyRocks. Reference pointers sound more plausible.
I spent time analyzing and deciding my usage of uuid7 from different perspectives. From the git logs, you can see it came at the last minute.
I'd encourage you not to switch databases, or at least to defer this for a while. I can't imagine you'll have issues with the amount of WAL written for quite a while, and by that time, the world could be quite different (OrioleDB might be mature! https://github.com/orioledb/orioledb)
Re: development velocity, IMO there’s a solid base product now. I feel like it’s a great time to make a solid change to help future velocity, but I’m not OP.
I do not intend to change the Postgres database or introduce a new one. I’m sure this won’t be an issue for the majority use-case.
However, I am open to learning more about alternate ways to efficiently handle Yjs state updates, which may be useful for a cloud version that would run at scale. If I were to go that way, it would not affect self-hosted users and would probably be via a reference pointer and not a database switch.
This is absolutely not an issue at the moment. Nothing to worry about.
I appreciate you at least considering the various options. If you do nothing else, tuning Postgres parameters, optimizing column ordering, and removing duplicated indices will be a great step forward that is completely backwards-compatible.
Ed: looks like it https://pganalyze.com/blog/5mins-postgres-jsonb-toast
Docmost does not depend on any Pro Tiptap extensions.
The team at Tiptap are doing something really amazing. I believe it is fair that they find avenues to make revenue from it.
I like Lexical, but I found Tiptap first and loved it.
I like the focus on UI (many open source projects missing this aspect)
- An export function (PDFs).
- An integrated diagram editor like Gliffy.
- History / diffs.
Outline is the closest to this so far, but we are in no rush, so we'll watch the development of this as well. Thanks for sharing!
I'm working at XWiki SAS [1] on tools to migrate from Confluence to XWiki [2], an open source and powerful wiki software that was born at about the same time as Confluence.
We have all this. We offer support and consulting, including for handling your migration. Our migration tools try to keep as much of the content and its feature as possible, and we work on compatibility macros for this.
Feel free to reach us, or me.
[1] https://xwiki.com
[2] http://xwiki.org
Noticed this example from your store embeds French flavor for me:
https://store.xwiki.com/xwiki/bin/view/Extension/Office365In...
2. Diagrams will come too. MermaidJs is next on the line. Other diagram providers like Draw.io and Excalidraw will come once I figure out an efficient way to handle storing and retrieving their raw data.
3. There is support for page history. No diff comparison yet though.
- consolidation of wiki together with your code's READMEs and generated docs (e.g. sphinx, mkdocs, swagger, etc., anything that outputs documentation from your codebase)
Note on the "integrated diagram editor", this brings up another feature (though less critical than above):
- by standardizing on a docs-as-code abstraction like mermaid or kroki, you can then leverage (a) diffable diagrams as code, and (b) quite a few relevant OSS editors.
See VSCode extensions for a few different implementations, but that said, if you pick mermaid, then the same diagrams work in the wiki tool as on GitHub, as well as local-first open content format tools like Foam, Dendron, or Obsidian.md, which is nice.
If you're open to it, please send me an email at dominic@mermaidchart.com!
I'd be happy to exchange an Amazon gift card for your time too!
- PDF Export - Oauth2 - Revisions - History - Permissions - WYSIWYG/Markdown/Diagrams etc.
[0] https://www.bookstackapp.com/
Unfortunately I’d never advocate for something like this at my work. Self-hosting doesn’t make sense in terms of total cost of ownership. I’d rather engineers spent time solving problems in our core business than making sure our wiki is online.
As with a lot of modern open source, the monetisation comes from providing a hosted/ supported cloud version so your engineers can spend their time solving your core business problems rather than making sure the wiki is online.
That said, it's a Beta, and they've put 12 months into it already to get it where it is.
It's great to have open source competition in this area, so the current lack of a cloud option should put it in the "awesome, I'll check it out, then wait for a cloud option" category.
The ability to self host also doesn't prevent someone, including the original developers, to also proving hosted services.
And since the presented tool is open source, it's also possible for another company to provide hosting.
Open source isn’t a business model.
Right, though that's orthogonal to the self-hosting aspect.
> Open source isn’t a business model.
Indeed but you can build a solid business model around open source. What do you mean?
Even if it's just a stop gap solution while we find a better solution to migrate to.
- Managing pages in git/other vcs as plain text, using any editor I choose. I can commit pages using git or other vcs, don't have to use the browser to add pages.
- Writing pages in some markup language, maybe not markdown, as it is not expressive enough in some areas. Maybe markdown is possible for simple pages and the wiki knows it is markdown from the file extension, but the wiki also allows more powerful formats like restructuredText, which can be extended by the user.
- Server-side rendering of pages, that can easily be cached (since pages are files, one could easily check the shasum of the file to determin cache validity), which makes display of pages almost instant, as opposed to laggy shitty confluence.
It's managed to strike a good balance of getting out the way and letting me mostly just write plain markdown, whilst being able to fall back to react components if needed.
With CD to GitHub pages on merge to main I think it's a pretty good experience
Or is it just you want a developer-native workflow to upload docs intended for the rest of the non-developer team?
In general, I would say that's a really bad idea. If you’re dumping this self-hosted (and probably bug filled MVP, as all are) on your team, yet never having to deal with the UI layer that everyone else does…it’s a recipe for revolt and tool churn.
I’ve seen this mistake a million times from technical founders. Same thing will happen with your marketing website CMS, after you realize static site + markdown + git doesn’t scale to non-dev humans and the headless CMS you picked (but never interact with) is actually trash in daily use.
This. I am so annoyed by all the quirks and silly dysfunctional behavior of confluence, when all I need is a developer friendly workflow, that actually motivates to keep documents up to date and allows diffing easily and quickly and blaming and all that good stuff you get when you have git or other capable vcs.
> In general, I would say that's a really bad idea. If you’re dumping this self-hosted (and probably bug filled MVP, as all are) on your team, yet never having to deal with the UI layer that everyone else does…it’s a recipe for revolt and tool churn.
I don't see how. Users of the UI could, without explicitly knowing, save pages creating commits themselves. Maybe it could be difficult to square that with collaboratively working on a document in realtime though. If I had to choose between the two, I would pick git workflows any day of the week though and it is not so often the case in my experience, that people really work collaboratively on wiki pages of documentation.
> I’ve seen this mistake a million times from technical founders. Same thing will happen with your marketing website CMS, after you realize static site + markdown + git doesn’t scale to non-dev humans and the headless CMS you picked (but never interact with) is actually trash in daily use.
That is, why I am suggesting my points as additional, not as replacement. The non-devs can have their clicky bunty UI, but please let me use efficient workflows as a developer and don't create a sluggish experience in the browser, that will never motivate any dev to maintain documentation inside of it.
Also markdown does not do the job. It does not have some of the necessary building blocks. It is good for simple pages and perhaps a readme, but when it gets to proper technical documents, I would rather have something more capable. For example restructuredText, where you can define custom directives and so on. I used that before to make a little wiki with document interlinking functionality when rendering and used it to write a thesis. It is very capable. But there are others like org-mode format, and asciidoc and more. All more capable than standard markdown. (And yet, confluence has already issues with standard markdown, lol.)
An alternative is, of course, not to force devs to use confluence for documentation. Keep confluence to the marketting and sales fluff, and let engineers use efficient tooling, that they are already familiar with and that accompanies the code, instead of dividing documentation out into confluence, where it will quickly become unmaintained and forgotten.
It'd be nice to implement the non-technical workflow as producing a pull request via a branch. Each save (even autosave after N minutes) could be its own commit.
The user could see their changes from their branch in near realtime. Markdown isn't an issue, it's a benefit, although explicit support for images and diagrams is needed.
The GUI workflow could see if an automatic merge works, if not, it is fine to require manual intervention. Another option is to swap branches, copy main branch, rollback main branch to the place before any conflicts emerged, and then apply changes.
Bonus points for using CRDT for handling multiple users working together on a page during a conference call on the same branch.
I wouldn't store the file format in the file extension; rather store metadata properly as metadata. Chances are that the application wants to hold a lot more metadata anyway, so you're going to need a metadata storage scheme anyway. (Yes, I am a lone crusader for eliminating metadata from filenames.)
One thing to remember: devs and tech-savvy people skip everything and look directly at the terminal commands/code. It’s the reason you should never insert the “don’ts” in your repository readme too high on the page: they will be the first things we’ll cut and paste :D
This is not a criticism; it seems you did a wonderful job. Just the feedback of one of many dummy experimenters that you might lose on that page :)
1. https://docmost.com/docs/installation
Also I would use a .env file to manage the env variables, without requiring the user to modify the docker compose file. It’s very likely that people will version the yaml file, so it’s not a good idea to keep secrets in plaintext there.
https://docs.docker.com/compose/environment-variables/set-en...
It's very useful to have a complete 'getting started' page that get you from zero to working, without assuming that the reader understands what every intermediate step means. But as you said, the parts that are dependencies for other products can be encapsulated so that savvy users can skip them easily.
Focus the energy of your own docs on your own product itself, and let the docs of your dependencies cover most of the general steps regarding those.
On the installation page, there is a link to the official Docker guide which comes first. That should help other users with an OS-specific installation guide.
Storing passwords or secrets in git should be avoided; the .env file structure allows you to leave untouched the yaml file. Anybody changing it? Git pull, and you’re ready to go, since you didn’t change the yaml file and you don’t have to substitute secrets again.
For secrets, a .env file is fine for local dev and docker-compose IMHO. The "hidden file" nature of a .env is a good fit for secrets. (For prod I prefer K8s Secrets or Vault or similar)
In the end it's just personal preference. I get where you're coming from.
Because for most small teams with the ability to run containers, that's going to be all they ever need - and it means your "let's try it" experience is just `docker run <my container image>`.
I'd strongly encourage you to explore the image with dive after to visualize whats been added on which command while you're changing the dockerfile
https://github.com/wagoodman/dive
I'd push back on that being a good idea though. It's okayish, but it'd be better if the software had no dependencies, falling back to file storage/embedded DB. But that's obviously scope screep, so probably not worth the effort if your chosen framework doesn't give you a drop in option for that. Basically ymmv, I wouldn't touch a software that nests multiple daemons into the same image. It's a hack for easier demos or transient starts on dev machines, but that's it.
Your orm does support sqlite though, that'd probably be better then nesting a database daemon
Will probably need to start with an Ubuntu image instead of Alpine to keep changes to a minimum.
Recommendations for an “rc-service” to use in this context ?
There is also good old supervisord, but I haven't personally used it in containers yet. https://docs.docker.com/config/containers/multi-service_cont...
You’ll need to point the entrypoint to /usr/bin/init.
That said, I have had to do this before and if I ever have to do it again, I will be going right for a base image that has systemd. Red Hat provides UBI images that have systemd in it for reasons similar to this. Assuming that a pod or deployment using something like podman is not an option, This what I would use personally.