this post was submitted on 08 Apr 2025
187 points (99.0% liked)

Selfhosted

46197 readers
385 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] just_another_person@lemmy.world 3 points 2 weeks ago (2 children)

It's an electron app that runs from the browser. Why would need it to run via docker?

[–] jogai_san@lemmy.world 4 points 1 week ago (1 children)

Ok, I updated my drawing, so the arrows are correct:

┌─────────────────────────────────────────────────────────────────┐
│ Browser                                                         │
└─────────────────────────────────────────────────────────────────┘
                                ▲                                  
                                │ :443                             
                                │ :80                              
                                ▼                                  
┌────────────────────────────────────────────────────────────────┐ 
│ Proxy (traefik)                                                │ 
└────────────────────────────────────────────────────────────────┘ 
     ▲                               ▲                  ▲          
     │                               │                  │          
     │ :3000                         │ :8085            │  :5001   
     │                               │                  │          
     ▼                               ▼                  ▼          
┌───────────────────────┐   ┌────────────────┐  ┌────────────────┐ 
│ DBgate (in docker)    │   │ pgBackupWeb    │  │ My custom app  │ 
└───────────────────────┘   └────────────────┘  └────────────────┘ 
     ▲                               ▲               ▲             
     │ :5432                         │ :5432         │ :5432       
     │                               │               │             
     ▼                               ▼               ▼             
┌────────────────────────────────────────────────────────────────┐ 
│ Database                                                       │ 
└────────────────────────────────────────────────────────────────┘ 

DbGate is connecting to my postgresql db. If I kill the container the communication is cut off. The ports 3000, 8089, 5001, 5432 are not open. How does DbGate load my postgres data then, if no backend? Sometimes I use it when my client messes up something thats only repairable in the db. Thats the exact scenario where its useful to run it in docker.

It’s right in their docs

Where? The app runs in the browser, but the data is still remote (from the pov of the browser)

[–] just_another_person@lemmy.world -1 points 1 week ago (1 children)

Again, no.

DBGate is an application running in your browser. Just like any other desktop application, except it's code is executed in the browser, and not a standalone window. DBGate uses the runtime platform of your browser to execute code and create connections to the database you're using. That's where you're getting confused. There is nothing running in the docker container except a dumb HTTP server that allows your browser to load the code to executed, just as if you had visited their website.

This same exact code can also be packaged to run in Electron as a standalone window in your desktop so it seems like its own app. Same exact code that runs in your browser, but using Electron to host and execute its code.

[–] jogai_san@lemmy.world 3 points 1 week ago (1 children)

Show me the docs. It really sounds like you're confidentially incorrect :-)

The app part is indeed just running in the browser. But it needs the data over an external connection. Explain how it can read/write the data to me.

[–] just_another_person@lemmy.world -2 points 1 week ago (2 children)

I...don't think I need to. It's all open source. Here is the DBGate repo right here.

If you're unfamiliar with all of this, that's your job to get educated. This is how browser-based JS software works. The "proof" is right there in all it's glory for you to peruse.

[–] jogai_san@lemmy.world 3 points 1 week ago (1 children)

I…don’t think I need to.

You dont need to indeed, but since you mentioned them first.

If you’re unfamiliar with all of this, that’s your job to get educated.

I'm a software engineer from way before the js hype, so I think I'm properly educated thanks.

The “proof” is right there in all it’s glory for you to peruse.

Indeed, here is the api part: https://github.com/dbgate/dbgate/tree/master/packages/api

[–] just_another_person@lemmy.world -1 points 1 week ago (1 children)

That is a LOCAL running interface. It's not something being run as a server-side interface in the docker container.

I'm not sure what point you're trying to make, but at this point, you're original concern and question has been answered.

[–] jogai_san@lemmy.world 0 points 1 week ago

The point is: DBgate is capable of running in a container which makes a connection to a database. You insist this is not how it works, but yet its the way I have set it up.

My question was if outerbase is usable in the same way. You clearly have not enough knowledge to answer that, so no, my question isnt answered.

[–] Markaos@discuss.tchncs.de 1 points 1 week ago (2 children)

If you're unfamiliar with all of this, that's your job to get educated. This is how browser-based JS software works.

The browser version cannot connect to Postgres without a server-side part, for rather obvious reasons - you can't just make arbitrary network connections from the browser. Electron build is of course different, as that doesn't have to deal with the browser sandbox.

By the way, here's a similar issue documented in Outerbase's repo:

Outerbase Studio Desktop is a lightweight Electron wrapper for the Outerbase Studio web version. It enables support for drivers that aren't feasible in a browser environment, such as MySQL and PostgreSQL.

Not gonna lie, telling people how they need to get educated on stuff you don't understand ticks me off.

[–] jogai_san@lemmy.world 3 points 1 week ago

Not gonna lie, telling people how they need to get educated on stuff you don’t understand ticks me off.

Thanks for backing me up. The fediverse needs to grow because this way it allows for people to be spout nonsense without being corrected by peers.

Btw, had outerbase running trough docker, but could not figure out a way to connect to my own pSql yet..

[–] just_another_person@lemmy.world -1 points 1 week ago (1 children)

I don't even know where to begin with this 😂

You had better alert the Internet at large and the developers of the apps being discussed here to let them that the very product they build is impossible then.

Oh...wait: https://reintech.io/blog/using-node-js-to-access-remote-database

A very basic example on how to do the very thing you said is not possible you say? While you're at it, you better go alert Zoom, Google, Microsoft, and anyone else with a WebRTC app that they aren't allowed to make connections to other things from the browser. It's totally against the rules and impossible.

🤣

[–] Markaos@discuss.tchncs.de 0 points 1 week ago (1 children)

Node.js is a web server. It doesn't run in a browser, therefore doesn't deal with the browser sandbox. That should answer your first dig.

For the second part, WebRTC is a standard that allows two WebRTC peers to communicate. You can't use WebRTC to open an arbitrary TCP or UDP stream to for example a database, unless said database decides to implement a WebRTC peer support.

[–] just_another_person@lemmy.world 0 points 1 week ago (3 children)

Friend, I've literally linked the DBGate repo. You can see yourself there is no server component running, and it's all in browser. It's literally called "web-based". Have a look here: https://docs.dbgate.io/web-app-config/

So in your world, you imagine that if you run this project, there is a server running...somewhere, and then it's forwarding all requests from the browser to this server, and the server is making the connections to the DB endpoint? Lolzzzz 🤣🤣🤣

https://github.com/dbgate/dbgate/tree/master/plugins/dbgate-plugin-postgres

[–] Markaos@discuss.tchncs.de 1 points 1 week ago

All right, I had some spare time today, so I went and installed this thing.

My setup is a bit more complex than the minimum necessary, but that's because I'm using an already existing Postgres database instead of installing a new one on my computer. It is as follows: Postgres running on a mini PC on my local network (192.168.2.199:5432), a browser running on my main computer, and a Debian VM for DBgate with two NICs - one is the default NAT interface (I'm too lazy to configure proper bridging / routing) and the second is a virtual bridge, testbr. On testbr, the host OS is 192.168.123.1/24, and the guest is 192.168.123.2/24.

I installed DBgate on the VM using NPM - npm install -g dbgate-serve, as specified in the documentation. Then I ran it using simply dbgate-serve, then connected to it from a browser running on my host OS as http://192.168.123.2:3000/. That works fine.

Then I added my Postgres DB through the web interface (to be verbose, I entered 192.168.2.199 as the IP address), created a table and inserted some dummy data. Then I wanted to do the next step, which is to block outgoing connections to port 5432 from the VM, but I noticed something very strange, given that DBgate obviously doesn't use the server as a backend to do the actual DB connection: this was in the server log

{"pid":7012,"caller":"databaseConnections","conid":"24d95082-ca6a-4dac-aa28-f3121bfc508d","database":"dbgate","sql":"INSERT INTO \"public\".\"dbgate_test\" (\"text\") VALUES ('haha');\nINSERT INTO \"public\".\"dbgate_test\" (\"text\") VALUES ('hehe');\n","level":30,"msg":"Processing script","time":1744395411096}

But it would be ridiculous to even suggest that the connection is relayed through the server, so it is probably some kind of telemetry. Makes sense.

Anyway, I went ahead and added the rules on the VM nft add table ip filter, nft 'add chain ip filter output { type filter hook output priority 0; tcp dport 5432 drop; }', and you wouldn't believe what happened next... The DBgate tab can no longer load data from the database. I can reload DBgate itself without any issues, and I can connect to the database from the same computer using psql and DataGrip just fine, but for some reason it seems to be affected by the fact that its server (which is only serving the HTML/JS files and doing nothing else, as you said) cannot connect to Postgres.

Weird how that works, huh?

[–] jogai_san@lemmy.world 1 points 1 week ago

Friend, I’ve literally linked the DBGate repo. You can see yourself there is no server component running

Yet you ignore I pointed to the api component in the repo...

[–] priapus@sh.itjust.works 1 points 1 week ago* (last edited 1 week ago)

there is no server component running

What the hell are you talking about? Just look at the Dockerfile.

CMD ["node", "server.js"]

You think that line isn't running a server?

Thr repo makes it very obvious that it runs a server that the webgui connects to. Its fine if you dont know shit but dont be a dick while being stupid.

[–] 8osm3rka@lemmy.world -1 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

~~An electron app still needs to be served by a web server, even if the actual business logic is all client-side~~

EDIT: Electron, not React...

[–] just_another_person@lemmy.world 1 points 2 weeks ago (2 children)

No? This is a client-side electron app. You'd need something to load the initial files, but that's it. There are no server-side running parts. Even still, there's links in the project here to load up the app right there. Each Major browser has ways to "install" such apps from there.

[–] 8osm3rka@lemmy.world 1 points 2 weeks ago

I had a brain fart and confused React with Electron...

[–] jogai_san@lemmy.world 1 points 2 weeks ago (1 children)

Well, I assume there is a backend which takes care of securely connecting to the databases. That way I can connect the backend to the internal network where I can connect to the database, and without exposing the database port still use this from the browser.

[–] just_another_person@lemmy.world 2 points 2 weeks ago (1 children)

Huh? This is a database client. There is no backend. You point it to a database, and it connects to the database. That's all it does.

I'm not sure what other backend you may be referring to, but it will use whatever network your desktop is using for comms.

[–] jogai_san@lemmy.world 1 points 2 weeks ago (1 children)

Are you sure? Because thats how dbgate works, and I thought this was similar.

[–] just_another_person@lemmy.world 1 points 2 weeks ago (1 children)

Yup. This is just a straightforward client. Unfamiliar with dbgate but just looked at the docs. It's also just a client as well. Unsure what other backend service you may have been referring to.

[–] jogai_san@lemmy.world 1 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

It seems there is a misunderstanding. To be clear, this is what I mean:

┌───────────────────────┐    
│ Browser               │    
└───────────────────────┘    
     ▲                       
     │ port 443 open         
     │                       
     │                       
┌────┼──────────────────┐    
│ Proxy (traefik)       │    
└───────────────────────┘    
     ▲                       
     │                       
     │ web port open to proxy
     │                       
     │                       
┌────┼──────────────────┐    
│ DBgate (in docker)    │    
└───────────────────────┘    
     ▲                       
     │                       
     │                       
     │                       
┌────┼──────────────────┐    
│ Database              │    
└───────────────────────┘    

This way DBgate serves the web app to the browser, but also acts as a 'backend' which connects to the database. This way my databases are not exposed to the web, only the proxy is, which handles domain name routing and http traffic.

That's not how it works, or maybe the arrows are pointing the wrong direction in your ASCII. DBgate is an in-browser application in the same way that the other posted is, just with different features. They both run completely in the browser, BUT the files need to get loaded there first right? So the docker version of DBgate is simply starting a tiny web server that bootstraps the client application into your browser when you visit the local port. It's right in their docs.

No server-side code at all, and in fact, you can kill the docker container after you get it loaded in your browser if you want to double check 😉