I know a place where they still do this. They've got an 8-digit user count, 7 digit monthly profits, all running on one server that costs something like $20 a month. They've downsized a few years ago to single-digit employee number and just sit there and collect profits. And this is why I'm now working for a company that casually dropped a few grand for a glorified CPU usage meter and a few grand on top of that for deployment tool that does the same thing that the old guy at a former place was doing with his trusty FTP client.
My production server running Win XP Home has to have the firewall off just to make all the super secret company internal networks work. SFTP would cripple us!
/s, except about the performance hit being stupidly unacceptable in 2024.
There's still a few sites I deploy changes to using ssh+rsync. ...which is made considerably easier by the fact that it's just a static website generated with Jekyll.
Don't forget ear files. Oh, and don't forget the abomination that is the executable war file when you're using Spring Boot but your company hasn't fully embraced it yet.
Unless you're using Linode or something other general purpose VPS which you have installed a Minecraft server onto, having to use anything other than a WebUI to exchange files with the server really strikes me as sketchy. A dedicated can't-run-anything-else Minecraft hosting provider even giving random users SSH access is sketchy enough but requiring you to use it to update the game... that level of not having an IT guy is just a security nightmare waiting to happen.
Guessing by your comment that you've actually rented a general purpose Linux VPS and not gotten suckered into Honest Pete's Discount CreeperHost. In that case, carry on.
The last time I've rented a Minecraft server was probably over 10 years ago, and as far as I can tell, at the time having to upload stuff through ftp was normal.
Although reading this thread has also taught me that I know nothing about how deployment works and I need to catch up on that.
I used to use rsync to copy data from my storage array on one machine to an external and an off site backup. Since a lot of it was code, it always took forever to scan all the small files, and I had to script unlocking remote partitions.
With encrypted ZFS, I can just zfs snap then zfs send, and it does the same thing at the block level, raw, so way faster, less data transfer, and no need to send a key or passphrase unless I need to mount it at the destination (meaning a cloud provider could never know the data, for instance)..
ZFS is also recursive, so if I have s/storage and /storage/stuff defined, I can snap and send either level, which makes it as versatile as rsync.
I remember joining the industry and switching our company over to full Continuous Integration and Deployment. Instead of uploading DLL's directly to prod via FTP, we could verify each build, deploy to each environment, run some service tests to see if pages were loading, all the way up to prod - with rollback. I showed my manager, and he shrugged. He didn't see the benefit of this happening when, in his eyes, all he needed to do was drag and drop, and load the page to make sure all is fine.
Unsurprisingly, I found out that this is how he builds websites to this day...
This is from before my times, but... Deploying an app by uploading a pre built bundle? If it's a fully self-contained package, that seems good to me, perhaps better than many websites today...
That's one nice thing about Java. You can bundle the entire app in one .jar or .war file (a .war is essentially the same as a .jar but it's designed to run within a Servlet container like Tomcat).
PHP also became popular in the PHP 4.x era because it had a large standard library (you could easily create a PHP site with no third-party libraries), and deployment was simply copying the files to the server. No build step needed. Classic ASP was popular before it, and also had no build step. but it had a very small standard library and relied heavily on COM components which had to be manually installed on the server.
PHP is mostly the same today, but these days it's JIT compiled so it's faster than the PHP of the past, which was interpreted.
