I have a similar setup, I use Caprover as a nicer way to manage docker. You can build whatever you want into the dockerfile then just map the user directory to a local one and port forward where needed.
If you want to run a web app through a domain with SSL then it's trivial to setup a nginx proxy container.
It takes minutes to spin up a new dev environment with everything setup out of the box including environment variables and access tokens.
Certainly, if the built-in "install-as-app" of major browsers work well for you, then it's great.
WebCatalog tries to make the concept simpler and more accessible to average users. Most people are familiar with the concepts of apps and app stores so our vision is to build an app store for web apps that gives users easy access to desktop apps (many not available elsewhere). A user doesn't need to know what is difference between a website or an app, they just need to open WebCatalog and install the apps they want like they usually do on their phone. For a power user, this might sound unnecessary, but this is proven wrong as there are plenty of apps like "X for Gmail" or "Y for Netflix" on Mac App Store and Microsoft Store. It is also the reason why companies like Notion and Slack build web-wrapper desktop apps.
One more point, we're not only letting users install chromeless window apps. If you give it a try, for example, with the Gmail app on WebCatalog [1], you can switch between multiple accounts using workspaces, set the app as the default email client, attach it to the menu bar or taskbar, etc. They're real apps with executables, not just bash scripts. And we're trying to integrate the web apps with your system and make it feel native-like as much as possible. And we're going to add many more features soon. In other words, we're trying to bring the experience that web-wrapper apps like Slack, Microsoft Teams, and Notions offer to every web app.
I've been bootstrapping WebCatalog since 2017. I and many people around the world use it every day. It's a well-tested idea. It's only now that we decide to launch the product widely.
Looking at the size of your catalog I'm going to guess that you didn't work with all those sites to distribute their apps through your site. Maybe I'm not understanding how this works, but wouldn't you need some sort of license to do this? If someone downloads the Gmail app from your catalog, but it doesn't work the same as the plain web client, they would probably blame Google and not you. I can't imagine Google would like that.
Yes, it's built with Electron. But I don't think there's anything wrong with the framework. Plenty of amazing apps are built with Electron, and they're fast and snappy. Without Electron, we'd never be able to bring WebCatalog to all major desktop platforms.
People use electron because it's literally the only option in many cases.
Can you point to a viable alternative? Multiplatform by default, with the option to build rich reactive UI? Plus text editing with a sane document model (via ProseMirror etc)? Fast math rendering (via katex)?
If so I will happily jump ship! Even Microsoft's attempt at a react native for desktop excludes Linux so it's a non-starter. The Rust community seems to be interested in solving this problem, and I eagerly await their solution.
Is there a way to do this on Mac where you can open several app windows and use ALT+tab to switch between them? I know you can use CMD+` to swap between Chrome windows but this is a productivity killer if you have to first ALT+tab to Chrome and then use CMD+` to get the window you want.
Thank you for bring this up. This is exactly what WebCatalog is built for. Every app you install through WebCatalog works just like a Mac app so you can switch between them using Alt+Tab.
For each app, if you need to, you can divide the app into workspaces (similar to how Slack workspaces) which you can switch between using Cmd+1, Cmd+2, etc.
A few months ago a wrote about how I solve this problem (https://www.viadog.com/replacing-environment-variables-aws-s...) and it works nicely for a small team with a small number of projects but this looks like a very nice solution when starting to scale a little bigger.
Hi everyone, I'd like to share Viadog Subscriptions which is my first product. It's targetted towards Shopify/ReCharge shop owners and helps to both increase revenue through upselling and reduce churn through gifting.
I'm happy to answer any questions and also open to feedback.
Bulk SMS spam would most likely come from someone with direct signalling access and not from individual SIM cards which would be trivial to detect and block by the operator.
It is trivial, even for someone not that technically oriented to send a mass SMS from Android, with the appropriate app. Since it's easier to sideload on Android, it would be even easier for a malicious spammer to pay people to install sketchy APK's that spam from the user's phone relentlessly.
This would be simple for the user to execute but it would very quickly be spotted by the operator as it's all from a single originating MSISDN.
Spreading the load over many users like your latter example would be a lot harder to spot, as would spamming through multiple SMS providers as you're diluting it (but it might also get picked up by the provider e.g. Twilio, MessageBird etc).
My point was that most spam originates from people with SS7 access and not SIM cards. It can also come through low cost SMS providers but is short lived as it's blocked the moment it's discovered or there's a complaint.
How does one even obtain SS7 access w/o a AUP forbidding this kind of abuse? Or are the Telco owners making more money not caring @ that connection level?
What's more, all you need is a broadband dongle and you can send SMS with a simple script straight from your PC - but as others already said, it's hardly a real source of spam.
I think there's an increasing amount of SMS spam being sent by random compromised consumer devices, which is probably what drove T-Mobile to take this sort of desperate measure. It would seem like notifying the customer is even more warranted in this case, though.
I just did a write up about how we use a secrets manager to load our environments allowing an easy centralised management across multiple projects/envs.
If you want to run a web app through a domain with SSL then it's trivial to setup a nginx proxy container.
It takes minutes to spin up a new dev environment with everything setup out of the box including environment variables and access tokens.