mirror of
https://github.com/stoatchat/self-hosted.git
synced 2026-07-21 04:25:24 -04:00
feature request: Allow connecting to self-hosted instances through the client applications #98
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @NaomiTheAshenOne on GitHub (Apr 24, 2025).
What do you want to see?
Adding a button to log into a self-hosted instance when in the sign in page of the client applications would make self-hosting an instance far more useful
@JackBinary commented on GitHub (Apr 25, 2025):
Seconded, being able to connect to a self-hosted instance in the app/desktop client would be very useful.
@distinctjuggle commented on GitHub (Nov 15, 2025):
It's kind of ridiculous to even advertise, "self hosted support" when neither desktop nor mobile clients support a user friendly way of changing the server in use. This is a pretty basic feature for a FOSS and privacy respecting app, and the neglect of it doesn't show a reason to place confidence in the project as a whole.
@insertish commented on GitHub (Nov 16, 2025):
You are welcome to help contribute this feature!
@diovudau commented on GitHub (Nov 16, 2025):
Before anyone does the implementation work as a volunteer, it would be nice to hear from the official people if this would be accepted into the normal clients, e.g. the one you can download through the google Playstore.
Or in other words: Does this feature not exist yet because nobody simply did it or is it because you want all users to use the stoat server instance?
(In opposite to: Recompiling and distributing your own app variant just to connect to your own server instance is the same as "feature not available" for a non-computer-nerd community. )
@distinctjuggle commented on GitHub (Nov 18, 2025):
I think you're missing the core point here.
This is a feature which is 100% REQUIRED to allow basic usage in self-hosted instances of stoatchat. This is a feature that definitionally comes with claims of self-hosted support. Yet, that isn't the case - and a community member had to create an issue requesting the core functionality to be added. That's extremely contradictory.
Why would I as a community member and end user want to contribute to a project which lies about basic functionality and seemingly makes no real efforts to supporting self hosting? Changing the endpoint in a basic GUI isn't a hard feature, but it's been ignored for the entirety of Revolt/Stoat's life. The docs for self hosting are currently out of date, and they've always been a mess for as long as I've checked.
The core point here is that it doesn't look like the leaders of this project want to support self-hosting and embrace FOSS. So why would I or any other community members want to try to put effort into a project that doesn't seem to care about FOSS? It's pretty hard to see any other interpretation when something as basic as this feature request wasn't present at the claim of, "self hosted options."
I'd love for this project to be a viable privacy and FOSS friendly alternative to Discord and Matrix. I think offering a viable alternative would drum up a lot of support, since there's plenty of people who have large issues with most every chat platform, FOSS or otherwise. Fully embracing self hosted options would be sure to grow a strong community, and I'd love to see that happen. However, it's pretty hard to get behind this project when self hosting isn't a pragmatic option for usage in the slightest. The claim that it offers self hosting yet lacks such a basic feature as this feels more like I'm being lied to than the project is still immature. It's hard to imagine how I'm expected to use this to any level when I can't use mobile and desktop clients - much less distribute it to friends and family for actual communication.
I'm not trying to be ungrateful for the project and the efforts behind it, but again the state of self hosting really comes across more as a lie, and who wants to contribute to that?
@insertish commented on GitHub (Nov 18, 2025):
Yes, we are open to having this contributed, we also have some guidance on how it should be implemented.
If we didn't have a desktop app, or mobile app, would it still be required?
We didn't for a long time, and the self hosted stack has always provided a web app (which can also be used on mobile).
The web app just had a major rewrite, and this feature could easily be worked in now that the dust is settling. It hasn't been done simply because there are so many things that have to be done competing for our time. (again, I have a day job so help is appreciated!)
Android and iOS clients are also quite heavily in development. There are core features which haven't even been built yet so I would say it is reasonable other things are taking priority in those areas.
Again I have to stress, we are all volunteers, we can only do so much.
NB. I don't believe we "advertise" self hosted support but we've always tried to maintain this repository where we could to allow others to run the platform for themselves.
@kaimakes commented on GitHub (Feb 10, 2026):
Hey, this has become more urgent lately as communities soon to be displaced from Discord are actively evaluating alternatives.
In practice, the lack of a simple way to point the public client at a self-hosted instance is a major blocker for non-technical users and large communities, especially where recompiling apps isn’t feasible. (This is not practical!)
Completely understand the volunteer nature of the project, im just flagging that clearer direction or prioritisation here could unlock a lot of real-world adoption. I'm sure this will in turn, produce results and greater investment and contribution. I appreciate the hard work.
@jasmeralia commented on GitHub (Feb 11, 2026):
I tend to agree that client support is truly necessary for mobile users, even if I don't think the characterization of "lied to" is accurate. The simple fact is that notifications are not going to be reliable at all for mobile users if they're not actively using the browser. Quickly renders the idea of getting notifications on my watch moot. And a chat system without notifications is... not very useful to me.
I'm not really savvy on mobile development, I work on backend systems (primarily IaC) at $JOB, but I'd be willing to help in any way I can if this is going to be actively worked on, even if it's just doing testing and reporting back results.
@Alexgopen commented on GitHub (Feb 12, 2026):
For self-hosted instances, the browser based web-app can be installed locally and used like a PWA to serve as your client on Desktop/Mobile. The main issue I'm facing while using it this way as mentioned previously is lack of push notifications despite configuring them as enabled. If notifications were working properly, then the standalone client isn't even really needed, as one can install the web-app itself to serve as the client for self-hosted instances, and this would remove the need to distribute clients for different platforms (Windows/Mac/Linux/Android/iPhone).
On Desktop (in my case, Linux Mint):
Screenshot example of web-app based client on Linux Mint
On Mobile (in my case, Android):
Screenshot example of web-app based client on Android
Note to @insertish : To me at least, the ability to self-host Stoat is its biggest appeal. I understand the recent Discord drama has lead to flooding of the main server and put strain on resources, but if self-hosting was more advertised as its main selling point and simplified for a general audience, then any community who wants to have their own chat could do so under their own control. I am imagining some kind of self-host launcher with a UI for simple configuration, management, and launching of your own Stoat instance. Then someone doesn't need to follow Github guides, know docker, run any scripts, do any manual mongodb insertions for invite codes, etc. At most they would need to rent a server (or host locally), get a free domain name, and then run the launcher to configure and start their self-hosted instance. This isn't far off from how Teamspeak servers are hosted and would do wonders for ease of use.
@jasmeralia commented on GitHub (Feb 12, 2026):
Browser based push notifications are pretty much dead on arrival under Android. I've gone around in circles on that before, and it's just not really feasible with how browsers operate in the background under Android. Maybe there's some special snowflake browser that does work right under those conditions, but the major ones do not.
Pretty sure it's even worse on iOS with how most browsers are forced to use a large chunk of the core iOS SDK (thus why you can't configure a proxy server on an iOS browser... if you want to use a proxy, you have to configure it through a provisioning profile that conflicts massively with any corporate device management like inTune).
I do not mind the Docker aspects, personally, I'm perfectly fine with handling that myself (biased here since I'm a DevOps Lead at
$WORK), but the client side of things is what limits more people from actually using the setup.