Extreme Persistency and Accessibility with a Remote Dev Server!

Published about 1 month ago • 4 min read

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, 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!


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!


Hi friends, Here's a quote from Deep Work which I'm 30% through the second reading round: Focus intensifies by getting used to NOT being distracted. And can improve with practice.” - “Deep Work”, Cal Newport An MIT recent study shows that when the brain forms memories or learns a new task, it encodes the new information by adjusting connections between neurons. They also remind of the principle of “neurons that fire together, wire together”, proposed by Donald Hebb in the 1940s. This is...

6 days ago • 3 min read

Hi! Today I want to share a security researching flow Disclaimer: I am not a security expert. Disclaimer II: Every story and example shown here were either made with Prior consent My own systems As part of a VDP (vulnerability disclosure) The WHAT For the next magic trick you’re going to need - A browser - A proxy - A pair of eyes Easy, right? I’m assuming most readers have at least 2/3 but never made them work together to get an insight into how their browser interacts with the...

20 days ago • 2 min read

Hi! Let’s say you’re an entrepreneur, you know what, a “solopreneur”. You have you own side gig and it’s making a few hundred bucks a month. If I told you you can lost the entire thing in a heartbeat because you missed something, you’d be anxious to know what it, right?​Rewind 34 months, I was sitting at my desk, assisting the frontend team in troubleshooting their configuration issue. As I opened the devtools pane and launched the network tab, my goal was to locate "config.json". However,...

27 days ago • 3 min read
Share this post