Uprock mounts

[dacian1662]

Hello,

First of all, great respect for the project!

I'm currently running some manual setups (1024 docker containers per service, each wrapped inside a vmware vm running flatcar) and i'm considering testing your solution. Flatcar handles high pressure very well and stable if all relevant limits are tuned high enough and resources are sufficient.

I was hoping for some pointers on the Uprock container - I'm failing to understand how the app maintains login persistence and what mounts in particular matter for this. Can't seem to find any readme for "adfly8470/uprock" - "/root/.local/share/" would be the obvious one but the app always reverts to defaults on container recycle.

Any wisdom imparted would be greatly appreciated.

Thanks,
Daniel

[engageub]

Hey,

Thanks for the kind words — really appreciate the support for the project!

Regarding the Uprock container, manual login is currently required and it uses OTP. That’s mainly why I think the process isn’t fully automated at the moment. While it would technically be possible to automate the login flow, it raises some privacy and security concerns around handling credentials and OTPs.

I’m not exactly sure where the credentials or session data are stored. From what I remember during testing, restarting the container usually required logging in again, which suggests the session state isn’t reliably persisted (or may be regenerated on startup). That’s likely why mounting something like /root/.local/share/ alone doesn’t keep the login state.

One thing to note: each login requires about a 4-minute delay before starting the next new container login, otherwise the OTP might not arrive properly. So when bringing up multiple containers, it’s best to space the logins out accordingly.

Also, if you’re planning to run large-scale deployments like your current setup, the test branch includes support for running more than 1024 containers, which might be useful for your use case.

If you experiment with different mounts and find where the auth/session data actually persists, please share it here so we can ask the author to update the documentation if needed.

Thank you

[Polaris0112]

i used gnome key on my wipter image. i can create a uprock version so you can test it.

hi, I have create a scripts to login progress, but I want to know do you know how to find out if it is already login?

[dacian1662]

Hey @techroy23 any news on that Uprock new image? Also, slightly off-topic, i'm using your URnetwork image, but it seems there's no persistence in that either (ie on every build, it created a new device in dashboard leaving the other one offline - wouldn't this affect device "reputation" via uptime reliability?). Thanks.

[techroy23]

Hey @techroy23 any news on that Uprock new image? Also, slightly off-topic, i'm using your URnetwork image, but it seems there's no persistence in that either (ie on every build, it created a new device in dashboard leaving the other one offline - wouldn't this affect device "reputation" via uptime reliability?). Thanks.

yeah urnetwork was built that way new client id on each start up. that adds layer of anonymity. so about uprock i forgot to upload the image. ill do it this weekend.

[engageub]

Hi,
It appears that uprock is working on cli version and has not officially made an announcement about it.
Please have a look at the following cli URL.

https://github.com/uprockcom/cli

Thank you

[dacian1662]

That's great news, the auth flow still looks like one time code dependent, unless I misunderstood the documentation. Still, this would massively trim down the image and less resource hungry I imagine. - @techroy23 happy to test and provide structured feedback as I do have the resources at-scale to deploy. Thanks!