101–110 of 328 posts
Deploy with scp/sftp.
Also it's very useful to have DEV.md file for each repo. It helps to remember how to build and deploy your project. Documentation for future me :)
Lots and lots of best practice exists specifically to help teams , and especially teams with some normal amount of turnover. The problems of a solo dev are very different than a dev on a team. Knowledge silos don't exist. Distributed expertise doesn't exist. There's no one to mentor, no shared vision to maintain, no intertia to combat. I consult on big complicated team projects. I also manage multiple solo projects.…
> I pay a service to manage backups so I can walk away from a solo project for months and know it's ticking away. Any recommendation of such service?
> I self-host three VPNs to protect my infrastructure heavy startup https://quantale.io
I am a big fan of Pritunl which is opensource and provides network security with a lot of ease. I am in no way affiliated with them, I am just a big fan of Pritunl. I use Pritunl to limit access to servers and web applications for my different teams. For each user, you can generate a profile and assign the servers and port they have access to on the server. For eg:
- Only dev team can access ssh port(22) on stage server and not open to internet.
- Any one in the team can access stage version(port 443) for testing purpose.(Not open to internet)
- Only I can access all ports on all Prod servers(only 443 open to public)
What hackers can't see, they can't attack. Especially the port 22 on your servers should only be accessible to you and not the internet.
I self-host one instance each of OpenVPN and Wireguard with Pi-Hole which is then used to access my Pritunl Server adding extra layer of security.
Each of these 3 servers can be hosted on Hetzner $2/month instance. With a mere $6, you can add an extra layer of security to your infrastructure. Pritunl itself also provides subscription so that is also an option.
https://news.ycombinator.com/item?id=28671753
If you want to discuss more about this or security in general, feel free to reach out to me on my email on profile.
Earlier quoted context omitted.
> spooky arcane oldhat sysadmin deploy techniques (scp release to prod hosts, run deploy script I never realised I was using spooky arcane oldhat stuff! I feel wizardly now. My projects (for small clients and myself) basically use this. - A "build.sh" script that does a local build of back end and front end - A "deploy.sh" script that scp's everything to the server (either a digital ocean VPS or an EC2 instance), run…
This is great. Until you need to roll back.
----------
Static website:
1. Setup NginX using a symlink to the current version
2. Copy the new files to a separate folder
3. Change the symlink to point to the new version
----------
REST service (behind NgninX reverse proxy):
1. Current version runs on port X.
2. Deploy new version and run it on port Y.
3. Update NginX config to use port Y and reload
4. If you need rollback, just reverse step 3.
This can be done using scripts or Ansible too if necessary.
I have no idea why there's nothing here saying "don't". Go and get a Heroku account, hook it up to your Github repository's master branch for deploys, use Github Actions for CI, and then get on with life. Yes, you'll pay more for a Heroku Postgres instance than you would for a VPS on Digital Ocean with Postgres running on it, likewise you'll pay more for Heroku Dynos than another VPS to run your application server. O…
They use self-signed certificates on Heroku Postgres servers without a certificate authority present in the chain. No chance to establish reliable peer verification. A shame, I would love to use Heroku more often without compromising security.
Not a solo founder, but I do a lot of ops professionally. Unless you have a specific reason, I say it’s best to avoid complicated tooling until later. k8s, ci, etc are all really useful and solve a lot of hard problems, but god are they a bitch to set up and then monitor, fix when something weird happens, secure from nasty people outside, patch when some update becomes necessary, resist the urge to “improve”, etc. Th…
> spooky arcane oldhat sysadmin deploy techniques (scp release to prod hosts, run deploy script I never realised I was using spooky arcane oldhat stuff! I feel wizardly now. My projects (for small clients and myself) basically use this. - A "build.sh" script that does a local build of back end and front end - A "deploy.sh" script that scp's everything to the server (either a digital ocean VPS or an EC2 instance), run…
This also solves the roll-back problem mentioned elsewhere. Just checkout the previous version (as long as you don't make any side effects like DB updates that are incompatible).
I admit, this requires relatively simple software.
I scaled to millions of users as a solo founder and still run the whole show myself. AMA if you like. Here is what works for me: CI: From the terminal, I run my tests and commit to git. Deployments: rsync Rollbacks: Never did one. If something breaks, I fix it and rsync the fix to production. DB: MariaDB k8s: I don't use it. Computers are very fast these days. A cheap single VPS will get you a long way. Nightmare: No…
Not a solo founder, but I do a lot of ops professionally. Unless you have a specific reason, I say it’s best to avoid complicated tooling until later. k8s, ci, etc are all really useful and solve a lot of hard problems, but god are they a bitch to set up and then monitor, fix when something weird happens, secure from nasty people outside, patch when some update becomes necessary, resist the urge to “improve”, etc. Th…
> spooky arcane oldhat sysadmin deploy techniques (scp release to prod hosts, run deploy script I never realised I was using spooky arcane oldhat stuff! I feel wizardly now. My projects (for small clients and myself) basically use this. - A "build.sh" script that does a local build of back end and front end - A "deploy.sh" script that scp's everything to the server (either a digital ocean VPS or an EC2 instance), run…
Not a solo founder, but I do a lot of ops professionally. Unless you have a specific reason, I say it’s best to avoid complicated tooling until later. k8s, ci, etc are all really useful and solve a lot of hard problems, but god are they a bitch to set up and then monitor, fix when something weird happens, secure from nasty people outside, patch when some update becomes necessary, resist the urge to “improve”, etc. Th…