We develop one or more apps that we deploy on-prem. An app for us is a git repo with a docker compose file. On-prem is either a Linux server or a Linux vm that we have ssh access to (normally via Wireguard vpn).

For app updates, we use ansible to ssh into machines, run pre-deployment scripts, pull git repo and docker images, restart containers and run post-deployment scripts.

It could be better, but it works for us.

The biggest bottleneck we have now is communication with customers, scheduling of updates, letting them know of breaking changes or new features, that kind of stuff.

The apps are provided "fully managed". They dont know and don't care about the details I just described, but they do need assurances that everything is done "properly".

What we think would help us a lot is a way to easily let them know of new releases of any apps they have installed, let them read release notes, docs, and be able to either deploy on-demand or schedule a deployment at a certain time.

Although having fewer things for us to do is nice, what is crucial is to oversee deployments and make sure they are successful (and intervene if not).

Is distr for us?

In a Pull Request's description, I typed `#` (eg. `#1234`) and the suggestions (coming from https://github.com/suggestions/issue/...) popping up are for completely random repos I have no affiliation with.

I searched google for some of the titles returned and got no results (using `site:github.com`)

Comments URL: https://news.ycombinator.com/item?id=46104699

Points: 5

# Comments: 0

I'm also available for contract work, check my profile for relevant links and contact info :)

My questions are, can I use this without embedding your js, does it support vanilla js frontends, and how easy it is for marketing folks to build and maintain your newspage (eg starting from release notes in markdown).

I think answering these kind of questions in an FAQ on your landing page would help. I could get the gist of your offering by scrolling but no real "aha!" moment. Too much text for not enough info. (For me at least).

Also, really glad your site works without js enabled, bonus points from me!:)

Also, I'm surprised "All your base are belong to us!" hasn't been submitted yet!

Curious as to why you store the data in the database in b64 as opposed to files on disk. What's the reasoning for that? Doesn't it make storage/backups/etc more complicated?

Not an expert myself, I opted for in browser encryption, in chunks, so as to avoid memory limitations (at least in some browsers, not FF yet), and in browser gzip so as to keep file size down and speed things up.

I find your niche quite interesting (journalists, whistleblowers) but given the high stakes of that perhaps an open source or more collaborative approach would be easier to promote.

Another idea I've tried out but not pursued, is some sort of browser extension/addon (I used nwjs, similar to electron), that offers client side encryption for any site (form field really). So you'd only post encrypted stuff to whatever service (email, reddit, hn, whatever) and only anyone with the key would get to read it (well, assuming they have the key and the same extension). Just throwing the idea out there, I'm sure others have thought about something along those lines before. The details to get it right are tricky (UX wise), but for your target audience it may be well worth the extra work.

Keep it up!:)

One is a webapp I wrote almost 20 years ago for my dad and it's still being used today. It runs on IIS and built with asp classic and vanilla html/css/js (no frameworks back then). They use it to track orders and invoices to suppliers/vendors and ensure what they receive is what they ordered.

The other, an electron-type app that saves people hundreds of hours per month by letting them bypass some bad UIs and interact with external services directly. It's been running for 6 years, only had to make very few updates, and it's the one thing I don't need monitoring for - not only it's been quite stable, I get called immediately if it breaks (eg when external services change their endpoints).

Just prototyping at the moment, but the goal is to allow users to not only share files (even big ones) but also forms, like Google forms, but encrypted and one time only (read once).

The use case I have in mind is allowing businesses to create GDPR forms (with private info, consent, etc), share unique urls with specific customers, and once the data is received by the business delete it from the server.

This could be useful to businesses that don't have a customer-facing portal, but have to deal with PII and the customer needs to consent and verify the data and what it's used for.

The data is encrypted client side (web crypto) and the password either shared in the url (in the hash fragment, also encrypted by a key stored on the server) or by other means (eg. could be the recipient's dob or id number or some other previously shared or known value).

Still trying to figure out the details, use cases, business value but the core backend is done so is the client-side crypto stuff. I managed to get chunked AES-GCM working so that it doesn't load the whole file in memory in order to encrypt it, it does that in chunks of let's say 2MB. Chrome also has chunked requests (in addition to responses) for sending the file to the server, but would probably need to come up with some other mechanism to get that working on other browsers (like send the chunks in multiple requests and append to a single file on the server, but that adds more complexity so I'm still working it out).

I'm most familiar with on-prem deployments and quickly realised that it's much faster to build once, push to registry (eg github) and docker compose pull during deployments.