I usually connect with my server via ssh in a terminal and run basic commands. What's a better, more efficient and modern way of doing that? Especially considering ai and documentation along the way? I wonder if there's a better approach than "connect from remote and act local". Is there a method to "code local and push to remote"?

I use a fedora server with podman, caddyfile and vi.

top 50 comments

sorted by: hot top controversial new old
[–] 5 points 6 hours ago (1 child)
  • [–] 5 points 7 hours ago (4 children)

    I ssh into it twice a year to perform updates but otherwise i leave it alone. Server's been chugging along for like a decade now.

  • source
  • hideshow 4 child comments
  • [–] 1 point 1 hour ago

    Twice a year is crazy. I suppose most of my maintainence is adding drives (I'm a creator and I definitely totally need to archive all of my footage), but I also run a fair few apps that have needed manual update steps, so I do all my updates manually so I can fix stuff if it breaks.

  • source
  • parent
  • [–] 7 points 6 hours ago* (last edited 6 hours ago) (2 children)

    Similar, but you might want to update more frequently with the huge number of critical security bugs being discovered by AI recently

  • source
  • parent
  • hideshow 2 child comments
  • [–] 5 points 12 hours ago (1 child)

    I spent a while getting Ansible to be able to setup and maintain my server(s). And ended up not using it as much as I should, mostly because the computer I used to run Ansible from became a "Steam Machine" so I'm rarely sitting on it with a keyboard now and I don't want to have personal info and keys on my work computer.

    But it was a good learning, and useful while I used it. Now I just use ssh and compose files directly.

  • source
  • hideshow 1 child comment
  • [–] 1 point 4 hours ago

    You upgraded from ansible to ssh. As someone forced to write yaml for ansible professionally and has used many other config management tools, I can only commend your success at escaping ansible.

    Try mgmtconfig.

  • source
  • parent
  • [–] 55 points 22 hours ago (2 children)
  • [–] -2 points 7 hours ago

    Usually I put handcuffs on her every night, to keep her off of me, and only feed her the highest grade sushi and meat. It keeps her hair shiny, keeps good health, and complaints down to a minimum. I make sure she gets adequate sleep on an expensive mattress while I sleep on a 2 inch futon on the floor.

    Oh wait... wrong kind of server.

  • source
  • [–] 5 points 14 hours ago

    self hosted gitlab. each server has a repo with all the docker configs and application configs. also have any scripts for the server itself on there as well, things like required libs, network configs, etc.

    I also have a repo dedicated for let's encrypt SSL that retrieves new certs every month. then on each server is an install script scheduled that pulls the certs down, installs them, and restarts any services automatically.

    should anything go wrong, I have a siem monitor that will alert me that a service failed to start etc.

    currently running four servers like this with varying degrees of complexity.

  • source
  • [–] 43 points 23 hours ago*

    I just use ssh and manually type commands. Keep doing it and you will get good and it will become second nature.

    No need to burn tokens on basic tasks.

    Master your tools. Learn awk, sed, just, etc.

    Some shell customisation can help. For example I'm fond of zsh-auto-suggestions and skim. Makes me quicker.

  • source
  • [–] 71 points 1 day ago (2 children)

    I wait for something to break. Then I yell "God fucking dammit, I don't have time for this right now!" and spend an hour triaging things before I just try docker down, pull, up and everything works.

  • source
  • hideshow 2 child comments
  • [–] 14 points 21 hours ago (1 child)

    same. or i just df and see / 100%

  • source
  • parent
  • hideshow 1 child comment
  • [–] 12 points 21 hours ago

    Early on I wrote a script for my user account to run df and save the output to a file, then a second script to read that file and if the drive was full send me an email.

    First, it failed because it couldn't send the email because the email service failed under full disk conditions.

    Second, it failed because it couldn't write the file to disk because the disk was full.

    Third, it failed because outbound SMTP was blocked by my ISP.

    I learned a lot about how well you can fail if you really put your mind to it. Now I have Home Assistant grabbing the disk stats for my machines and flagging anything over 90%.

  • source
  • parent
  • [–] 10 points 18 hours ago (2 children)

    A mix of prayer and bash scripts.

  • source
  • hideshow 2 child comments
  • [–] 10 points 19 hours ago

    It’s good to get comfortable in the command line, including over ssh.

    Especially considering ai and documentation along the way?

    If I am going to ask AI or Google about something, I just do that to help me find the answer and then apply the answer myself. That way I learn, and can double check the AI isn’t hallucinating, at least on in obvious ways.

    As for documentation, I keep a notes folder with detailed notes on manual configuration I’ve done, how and why, and the things I’ve learned along the way. I’ve found it’s both useful to help remember the things I’ve learned, and it is useful to go back to refer to.

  • source
  • [–] 11 points 20 hours ago

    I write my NixOS configs in my PC, commit to the repo, then push it to the server. Then SSH in, and apply it. Or more likely, MOSH in.

  • source
  • [–] 2 points 14 hours ago

    I have a git repo with all my docker files, config, notes, etc. I have a main overview file covering the overall system and then a directory for each machine. I edit things on my local machine, then scp and ssh to the various remotes. Once I’m happy with my changes, I commit and push to my Forgejo install on my NAS in case my main computer fails. Secrets, passwords, and keys are in my Vaultwarden.

    I don’t use AI for it, but a local model could probably give me the commands to do whatever I wanted based on the repo.

  • source
  • [–] 9 points 20 hours ago

    I've been using a program someone on Lemmy has been writing: SSHPilot. It helps keep my server list organized and can easily ssh to the machines or open up a file browser for easy drag and drop of files if I have some quick files to move around. It copies ssh keys easily as well.

  • source
  • [–] 4 points 17 hours ago

    My target is terraform to provide VMs on my miniPC and ansible to configure them. For my nas, probably a basic distro then some ansible stuff to setup stomate.

  • source
  • [–] 16 points 1 day ago (1 child)
    load more comments (1 reply)
    [–] 21 points 1 day ago (8 children)

    Ansible is one way to "code local, push to remote(s)". Can define so-called playbooks, which is basically just a script, to do reoccuring tasks like e.g. updates.

  • source
  • hideshow 8 child comments
  • load more comments (8 replies)
    [–] 15 points 1 day ago (1 child)

    "code local and push remote" is only more efficient if you have a faulty connection with ssh or want to use a GUI editor that doesn't support remote connections. What you're doing is good. You can scoure for more "modern" ways that might have more glimmer and sparkly lights, but it won't improve efficiency.

  • source
  • hideshow 1 child comment
  • [–] 2 points 11 hours ago

    Declarative configuration (like docker compose) is basically "code local, push remote", and it has a lot of benefits, including improving efficiency because you have a clearer idea of exactly what is set up on the server, to make it easier to debug or make changes.

    Contrast this with just sshing in and running a bunch of commands to install something. Then coming back months later and wondering "what files did I touch? what packagea did I install? Hmm dpkg log says I added X but then later I removed it, so was it important?" Etc.

  • source
  • parent
  • [–] 3 points 18 hours ago

    I'll take the maverick and share my niche position. I did most if not all my proxmox setup and configuration via complete reliance on LLMs. Now, before anyone says "why would you do that", and I'll be straight up. I was high for all of it, and not a small blaze I'm talking regularly stoned for months. And I'll say it "got me by" for the frame work. It worked? Sorta. Music, Plex, immich, docker, arr stack, podman. Now, I can't say I fully understand it still and I've done a lot of changes since that point last year and I figured it out by asking the model to backtrack what we did and I wont lie it helped me better learn how to question the models for my job, and It did decent documnetation over my server. But again, I was literally high doing it

  • source
  • [–] 11 points 1 day ago* (last edited 1 day ago) (2 children)

    I created git repos on my main workstation for each homelab server/service I maintain that keeps:

    • documentation
    • notes
    • lessons learned
    • scripts, configs
    • runbooks
    • backup details
    • security audit details
    • log items that need attention
    • infrastructure

    I just point a local LLM (offline model that runs on my workststion) into those repos and ask it to perform certain things on those servers. It can do things like update packages, install packages, make config changes, set/check permissions, read logs (and fix errors in real time), and check the health of the overall system.

    I have it run pre backups before making changes, then post backups once its done.

    Once changes are in place and everything is running okay, I ask it to update documentation in the repo and tag the release.

    I use opencode that connects to a llama.cpp service. opencode lets me gate the AI so that any elevated commands that it needs to run (e.g. sudo or ssh), I have to approve it. It cant just go around making changes without permission.

  • source
  • hideshow 2 child comments
  • [–] 2 points 17 hours ago (1 child)

    What models are you using? What hardware are you running them on? I’m curious if I can replicate your success

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 16 hours ago*

    Hardware I'm running:

    • 8/16 AMD CPU
    • 32GB system RAM
    • 12GB GPU VRAM (AMD)

    I'm mainly using these MoE models:

    Qwen-3.6-35B-A3B

    • Q4_K_M quant quality
    • 128k context (conversation length before it compacts)
    • Gives me about 260 prefill and 19 token gen speeds

    Gemma4-26B-A4B

    • Q8 quant quality
    • 128k context length
    • Gives me about 190 prefill and 14 token gen speeds
  • source
  • parent
  • [–] 3 points 20 hours ago

    I use Gitlab for all configurations ans then I have a Gitlab runner in my K3S cluster so I can deploy locally for free

  • source
  • [–] 3 points 20 hours ago

    I deploy with ansible keys and install ssh with a keys-only config and only ansible access.

    Then I run some standard installs and configs with ansible and all future updates to apt, apk and docker are done with one ansible playbook.

    I don't include the ansible host itself in the automation, nor my workstation, just to prevent everything from being broken at once if something goes wrong.

  • source
  • [–] 1 point 16 hours ago

    Everything is in docker or a virtual machine that starts on boot. Docker containers are managed with Dockhand's web ui. Once a month I ssh and "sudo apt upgrade" but that's it.

    I tried to use olivetin to avoid having to ssh but I ran into errors I haven't had time to investigate yet.

  • source
  • [–] 7 points 1 day ago

    nixos, mostly. It has a very steep learning curve but if it breaks I’m just "whatever, rollback now, fix properly later".

  • source
  • [–] 2 points 18 hours ago

    I have a kubernetes cluster inside of Proxmox vm's, generally I write a deployment, commit it to a git repo and then use argocd to deploy it in the cluster.

    This is not something I would advise to anyone but the clinically insane, but for me there is a certain zen in having everything in git like that. It's for me the only way I can manage the 60ish applications I run without it having a permanent spot in my brain.

  • source
  • [–] 6 points 1 day ago

    Nothing wrong with good old ssh. My VMs are different enough that building and maintaining ansible playbooks or something similar would be a bigger task than actually doing it in the traditional way. Maybe I could benefit by building simple playbooks to populate user accounts, ssh keys, smtp relay settings and other common things, but I don't really set up new servers that often that it would justify spending time to set up tools for that.

  • source
  • load more comments
    view more: next ›