Extreme Persistency and Accessibility with a Remote Dev Server!


Extreme Persistency and Accessibility

The Problem(s)

Over the years, I had difficulties with keeping my work locally, for many reasons: I didn’t always commit and push, sometimes I either forgot or it just didn’t make sense.

When I left my computer at work, again either forgetting or just not needing it at home (at least I thought so), I was practically useless. Sometimes I found myself wanting to fix something or trigger a process on the go, and sometimes I had a eureka moment I wanted to document right away. On many other occasions, system resets, and human errors made me lose work when the local environment failed me. Not often, but once a year was enough for me to find a solution.

I’ve been using Neo/Vim and a Multiplexer for years, for me, it’s always been and still is - Tmux.
While these are great for local development, they become a force multiplier when used remotely!

I’ve decided to set up a dedicated development server that has my codebasea, which is synced with GitHub for version control (duh). Tmux manages my sessions (I use my own plugin for that), while Neovim is my familiar environment of choice, locally and remotely, not only being the best editor to ever exist (😅) but also a terminal based IDE that I can attach myself to remotely, over any type of secure shell.

The Solution(s)

To fix my problem I started building a robust solution I built quite a stack to handle everything, so buckle up, this takes you from deployment, through persistency, backups and security, and all the way to accessibility. Mind you - *this is a first iteration*. There's lots to improve (and I'd be happy to hear feedback from others who have gone down the same road):

1. Set up a terraform template that’s easily deployable should I encounter disaster. I won’t bore you with details, but for security measures, I made sure it is deployed on a private subnet, doesn’t have an SSH key, but rather has an SSM Core role attached, so that I'll be able to create private session from my shell using the AWS CLI plugin for sessions. This is the recommended way, unless you’re doing something like I’m about to explain in step (3) in which case ignore SSM, and checkout the alternative. TF provides the freedom of destruction, intentionally or not, while letting me reproduce the system within minutes.

2. To create the image, I started by running a user script to initialize via the TF template. When it became too much, I moved to a standard Ubuntu image on which I install everything needed using Hashicorp’s Packer. The same can be easily achieved with NixOs(!), and the only reason I haven’t done that is lack of complete familiarity with it (which I intend to solve soon so stay tuned!)

3. Next I needed to figure out my connection. With the technology above you’d imagine that SSH would be the instinctive choice, however, SSH can’t roam, it’s easily interrupted, and it gets very hard to type through if the connection isn’t perfect. These, and other features make it sub ideal. What is then? Mosh! A “mobile shell” designed exactly for these kind of purposes. It can overcome roamaing networks, the latency is close to nothing, and when typing it creates a seamless experience which is enjoyable! The one downside it does have, is that much like SSH, it requires working against a public instance with a key. This can be mitigated by using a jump server or a VPN, as well as narrowing down the allowed addresses but I’ll won’t dive into that at this point. Here's a great private VPN you can set in minutes!

4. To make sure my env is ready for me I needed my dotfiles to sync, while I could sync it rather simply with GNU Stow (checkout my dotiles README.md), I wanted this automated. This part is run through a hack script I made, but it's yet far from perfect: I recently came across the (very not new) rce project, and the modern alternative chezmoi which I’m working on testing both.
So far, just cloning and stow did their thing, but sensitive files (like my zshrc) don’t yet have a satisfying solution.

5. Now for the fun part, I run mosh and then tmux attach once I'm connected. That’s it. I’m in attached to my working session(s) and can keep going where I left off. The cool thing about mosh is, that when running through mobile terminals the connection is way smoother and nicer to work with. This can ben even further improved with an apps like Terminal7 that works over webRTC (let me know if you’re interested in more about that), which provides a very unique touch experience with a remote shell using Tmux panes!

6. When I'm done, I "git commit" and push, then "tmux detach", and I'm done. The server even goes to sleep at night with an automated startup time on my working schedule, and a small command to start it on demand I have aliased locally ("aws ec2-instances...")

Phew, this was a quite a bit for an email.

So, if you’re interested in watching a workshop going through all of the above step by step, please let me know!
Reply to this email or hit me up on any other platform.

If you found any mistakes, or have any comments or questions please reply and let me know as well.


In this week’s news I won’t share too much as this email is long as it is, but I can’t ignore the ramble around npm and how one developer messed the entire system up with a prank! More here and here.


Thanks for tuning in, have a nice weekend!

ESPRESSO FRIDAYS

Every once in a while I send hand picked things I've learned. Kind of like your filter to the tech internet. No spam, I promise!

Read more from ESPRESSO FRIDAYS

Thank you to our sponsors who keep this newsletter free to the reader: Aikido is your no-nonsense DevSecOps platform. One central system that shows you what matters and how to fix it, from code to cloud. So you can get back to building. Try Aikido today! We’ve all been there – that heart-stopping moment when you realize you’ve accidentally exposed sensitive information. Today, I’m sharing a personal story and introducing a tool that could save you from a similar nightmare. The Nightmare...

Hi friends! Today we’re diving deep into improving your terminal history management. Exploring techniques that can transform your command line experience from frustrating to fluid. Whether you’re a CLI novice or a terminal titan, these methods will boost your productivity and smoothen your workflow. To do that, we’ll explore three levels of terminal command management, from basic to advanced. Not actually running on my phone 😅 1. Basic: Built-in (mostly unused) tooling: Even without...

Hi friends, Tmux is a fantastic tool for managing terminal sessions, but it has its limitations. One major drawback is the lack of a floating pane feature, which can make navigating between different panes cumbersome and inefficient. Me frustrated with Tmux lack of floating panes while Zellij is killing it... Most users workaround this by creating new Tmux windows or panes, or by using hidden splits to zoom in and out. These methods work but can be inefficient and require many keystrokes,...