
Ask HN: How do you work efficiently on remote servers? - filsmick
It seems there are a thousand solutions for remote editing, but none is perfect. Cloud9, git, rsync, rmate, vim or emacs on the server (but you don&#x27;t have your familiar setup unless you sync it), FTP, scp...<p>What do you, professional developers, use for you day-to-day work on remote servers?
My thought was that vim &#x2F; emacs &#x2F; rmate + Sublime for configuration files and git for well-defined projects were the norm, but I&#x27;m curious about what people use for their work.
======
drKarl
Well, if for work you mean programming, you either work locally with a full
IDE and deploy to a server, or if you have to work remotely then zsh + tmux +
vim, and put some time in learning all three, and superpower them with the
plugins you need. Ideally you do both, that is, learn how to use efficiently
zsh, tmux and vim, and maintain your dotfiles, experiment with some plugins to
have your curated list of plugins, and then if you need to work remotely you
will feel comfortable, and when possible you can work locally on an IDE. If
you do that, you will install Vim plugins for your editor of choice anyway
(Vrapper for Eclipse or Vim plugins for IntelliJ Idea, or for Atom, Sublime,
etc). There are also some plugins to remote-edit files in editors like Atom or
Sublime

------
auganov
TRAMP mode in emacs let's you edit remote files, do dired etc through ssh, so
that mitigates the dotfile syncing problem.

edit: also sshfs, tho that isn't always a smooth experience

~~~
rebelnz
+1 for tramp mode. Nice to have all local .emacs configurations/modes
available. Not that I endorse editing on production servers ...

------
stewartbutler
I use ssh + tmux + emacs. Security policy states no local copies of
development files are allowed at my workplace without special authorization,
which I never bothered asking for.

Migrated my emacs configuration to the remote server as a git repository,
along with any programs that aren't available (e.g. git, which I use for
unofficial code; official code is managed via perforce). Use GNU stow to move
those configurations and binaries to the right places. If I need to move non-
confidential information around I collect it in an emacs buffer and then use
M-x compose-mail to send it out. The home directory is an NFS mount so I can
also mount my home directory and exchange files that way. Etc, etc.

I also set up a lightweight Arch virtualbox VM that I SSH out of, because I
really don't like the available Windows terminal applications, and every so
often I need a local Unix box for some random reason.

A lot of my coworkers use Sublime and remote file editing, but I work faster
when using Emacs (comint-mode is a godsend). We mainly work in Perl,
Javascript, and HTML so none of the bigger IDEs are really appropriate.

 _Edit_ Since people seem more interested in the Sublime workflow, I asked for
a few more details. Coworker replied: "Sublime SFTP [...] you might want to
mention that the only advantage to SFTP over remote mounting the server is the
save time, as with SFTP, you save local and push in the background, meaning
frequent saves don't constantly stall workflows. Otherwise, there is no real
advantage over just mounting directly." It is worth noting that he is working
on a Mac, which has some severe bugs [1] when it comes to NFS mounts, and
Samba has some latency issues in this instance.

[1]
[https://www.google.com/search?q=nfs%20slow%20mac](https://www.google.com/search?q=nfs%20slow%20mac)

~~~
filsmick
Thanks for answer. I'd love to learn about what solution your Sublime
coworkers use, as most people here use emacs / vim and I'm most proficient
with Sublime.

~~~
joeyspn
Probably they're using the "Sublime SFTP plugin" by wbond... I usually use
nano on the remote server and sublime remotely via ssh with this plugin. But
to be honest it is just for small tasks. 95% of the time we work in local
servers with Vagrant/Docker (shared folder --> git push), since our
deployments aren't _that_ big.

~~~
filsmick
I tried it, but I can't get used to navigating the filesystem with the command
palette. It just looks weird IMO.

------
tomkinstinch
On projects too small to have a workflow for automated deployment (let's be
real: not everything is worth the overhead of setting up all of those tools),
I've found the duo of Sublime and ExpanDrive[1] works well. The latter mounts
a server that is accessible via SSH as a local drive (it's essentially a nice
GUI for something like sshfs).

Otherwise, some combination of tmux and vim/nano/emacs.

1\.
[http://www.expandrive.com/expandrive](http://www.expandrive.com/expandrive)

~~~
mmccaff
I agree, being able to use your favorite local IDE to load and edit remote
files can be very convenient.

On OSX, I use Panic Transmit's "Mount as Disk" feature. I've also heard good
things about a product called WebDrive for this use case.

------
Revell
For me, it's a combination of tmux and vim. Deployments are done using
Puppet/Ansible, so no need to manually run any git commands. Also, I hardly
ever really manually change anything on remote servers and if I do, I make
sure to put it in Puppet/Ansible immediately after.

------
nanidin
I use rmate + Sublime Text for a pretty seamless remote editing experience
when I'm just dealing with a few files. It's really nice when you're editing
config files or when you want to skim through log files. I followed a guide I
found on Stack Overflow[1].

[1] [https://stackoverflow.com/questions/15958056/how-to-use-
subl...](https://stackoverflow.com/questions/15958056/how-to-use-sublime-over-
ssh/18538531#18538531)

------
mprat
I also suggest keeping your .vimrc / .bashrc / .screenrc / whatever other
config files you like in some kind of git repo so you can sync your config
files to the remote machine nicely. The other nice thing about this is that if
you have a remote that you don't use very often, you can either git clone the
repo and rake / make to install, or even wget the file and move it in place
manually.

------
laumars
Depends on the servers and the project I'm working on.

\- Sometimes I mount the remote servers file system locally over SSH (sshfs)
so I can use my local development environment. I generally do this when I have
more complex projects (eg quantity of files) and there's some prerequisites
defined on the server (ie it's easier to develop on the server than it is to
mimic the set up on my local machine)

\- Sometimes I use tmux and vanilla vi / vim (I don't generally bother with
plugins / config for editors so I don't miss them when jumping onto new
systems). I generally only do this if it's small changes though. The kind of
situation where it would be quicker to SSH in and make a few edits than it
would be to follow a stricter development and deployment model.

\- Sometimes I develop locally and then push the changes remotely (usually
using rsync, scp, git). This is usually for new projects and where there
aren't prerequisites specific to the remote host.

My preferred development model would be 1 (as it's ridiculously lazy), then 3
(as it better follows sane development and deployment models). But sometimes a
job simply requires you to make quick edits via vi; and thankfully I feel as
at home in vi as I do with most GUI text editors.

Just to add, there's only two config files I ever need to worry about:

 _.tmux.conf_ which I only put on a small handful of development machines
where I'd like detachable sessions from multiple client (eg home/work/etc).
But generally I will run tmux locally.

 _env_servers_ which is an epic environment script (like .bashrc) that I can
call in as and when and it has a whole stack of aliases, functions and such
like optimize my workflow. I've also set up an alias on my local machine to
auto scp my env_servers script to any server I SSH into. Thus keeping
env_servers available and up-to-date.

------
lg
I only work on a remote 'server', by which I mean my ubuntu desktop. I hate
linux gui's so I use a mac laptop and ssh into the linux box, and run emacs in
Terminal.app. For the occasional times that I need to step through java code
with a debugger, I chromote in and fire up the IDE, but I don't actually use
it to code.

------
dankohn1
Not to detract from the excellent answers, but I suggest you step up a level
and think about how to minimize (and ideally eliminate) the amount of remote
editing you need to do.

In particular, the Twelve Factor App
([http://12factor.net/](http://12factor.net/)) (by the founder of Heroku) had
a big impact in my thinking of how to remotely deploy and administer. In
particular "1\. One codebase tracked in revision control, many deploys" and
"X. Keep development, staging, and production as similar as possible". Note
that these approaches are applicable to any hosting provider and technology.

Now, there are times (especially when you're debugging a breakdown in dev/prod
parity) where it is enormously helpful to ssh into a remote machine. But I
would endeavor to minimize those occurrences.

------
falcolas
Vim, mostly. The customization is remarkably easy, just copy my .vimrc and
.vim out to the server. I have a folder containing all of my dot files which I
sync between servers, and a simple bash script which creates softlinks to them
in my home directory.

However, I don't do remote development as much anymore since I picked up the
habit of using Vagrant locally. Now I can edit the files locally (though still
with Vim), and debug them on a local VM. Throw in Salt and Ansible for
orchestration, and once I get my local VM working, I know my remote end will
work as well.

~~~
gknoy
How do you share the files with your Vagrant VM? When we tried that at work,
we noticed that trying to have a git repo on a share with Vagrant (rather than
having it created within the VM's filesystem) was VERY slow.

~~~
falcolas
I hear you - Virtual Box is getting worse and worse in terms of being able to
interact with the host in anything resembling a timely manner. I wish the
competition in the free VM space was better.

To get around this shortcoming, the sharing is mostly one way: from the host
to the VM, via the default shared folder. I've not had problems with VBFS when
managing files in this manner.

There have also been times where I have implemented watch scripts against
files on the host, which triggers a rsync to the guest's normal file systems.
From there, the file system behavior is more like what we can expect from a
typical virtual machine.

To support workflows similar to what I do against non-local VMs, I've worked
up some wrapper scripts which allow me to interact with the Vagrant VM via the
usual ssh, scp, and rsync. When running "vagrant up", I also write out the
VM's SSH configs and a ssh alias concatenates these with my base .ssh/config
file.

------
atmosx
FTP? People still use FTP??? That's a protocol from another era, was designed
to work in a way that's not compliant with today's best practices. The only
FTP server I have runs on a Raspberry Pi file-server I have at home. There's
no firewall in that little gem running.

As for tools, well vim is my default editor so:

vim (really lots of plugins, themes, extension support, personal .rc, etc.) +
tmux (tmuxinator for projects) + ssh (heavy user, I use sockets to keep the
connection up, use keys-only access, fine-tune the algorithms I use, etc.).

~~~
krapp
>FTP? People still use FTP???

Of course.. people never stopped. Anyone using Wordpress, for instance, will
almost certainly require developers to use FTP. For most shared hosts, FTP is
the default (if not only) available method for getting files on and off of the
server (and yes, people still use shared hosting as well.) I would even
venture to guess that "Save in Notepad, FTP to live server and F5 to see if it
worked" is still the most common web development workflow in existence.

------
notacoward
I do _all_ of my development on a machine in my home office, so I have the
same files and tools whether I'm downstairs or across the world. So mostly
it's ssh/vim/cscope. I build/test on other machines, so throw in rsync as well
- most often directly, but occasionally into an sshfs-mounted directory
(actually editing via sshfs is a bit painful sometimes). When things seem
particularly flaky I'll use tmux to keep stuff going through disconnections,
but usually I can do without.

------
nemoniac
I find emacs with tramp unrivalled. Set up once then just open & save remote
files by name from your local emacs. Switch to sudo as required.

No need for dotfiles or tools on the remote.

------
vegancap
I'd argue you shouldn't be working on remote servers at all. Ideally you
should be working locally and deploy using Capistrano, Jenkins, Bamboo or git
hooks etc.

~~~
filsmick
Sure, that's ideal, but what if you have a small laptop? It would be nice to
make use of the power of your server to compile more quickly, and speed up
your development cycle, right?

~~~
simon_vetter
have a buildbot/jenkins set up which runs your test suite on a buildslave
automatically when you push to a git branch?

I would still run my editor locally (your pick. I use vim almost exclusively).

~~~
filsmick
and do that for every project, even small throwaway experiments?

~~~
QuercusMax
If it's a throwaway experiment, it shouldn't take too long to compile locally,
I would think.

------
chatmasta
You learn how to use the terminal, and only the terminal.

I recently read a blog post of a guy who started coding on a cloud VM using an
iOS SSH app + bluetooth keyboard. He never stopped. The setup forces you to
only work with SSH and eliminates distractions.

~~~
filsmick
Oh, yes, that: [http://yieldthought.com/post/12239282034/swapped-my-
macbook-...](http://yieldthought.com/post/12239282034/swapped-my-macbook-for-
an-ipad)

I've read it a while ago. Of course if you only use command-line editors, it's
nice. But some people prefer Sublime or other graphical editors.

------
gsz
mosh + tmux + emacs

I can't believe how few people mentioned mosh. I work on remote boxes "across
the pond" all the time and it makes a huge difference. Laptop going to
standby, VPN dropping, slow connection, all handled perfectly.

~~~
atmosx
Whenever I installed/used mosh (linux RPi/arm7 of FreeBSD x86) the CPU went
crazy :-(

------
filsmick
Since a few people mentioned Vagrant: can I use it to set up a production
environment locally, with all the system dependencies, configuration files,
and then pushing it to production? If so, is this the recommended approach?

~~~
snowwrestler
I'm not a Vagrant expert. I think it's possible to just ship a Vagrant file to
the production server and turn it on, but I think the real value comes when it
is used with a configuration management solution like Chef or Puppet. Use that
to standardize between production and Vagrant, and then you can just deploy
the application from one environment to the other without worrying about
environment problems.

------
vbezhenar
I'm working locally using full-featured IDE and publishing my work with simple
shell scripts. When I need to edit files remotely, I just use vi. I know it
well and it works perfectly even over slow network connections.

------
stevenspasbo
I basically spend all my time in my terminal anyways so it's pretty similar to
how I work locally.

SSH into the box, checkout my dotfiles from github (or SCP them), edit text
files with emacs, or whatever else I have to do.

------
gear54rus
I find WinSCP to be a good way to work with remote servers. It can use
whatever editor you may like (ST3 in my case).

Supports full directory synchronization, has a nice UI and can be installed on
a flash drive.

------
nailer
If latency is a concern, use a remote file system (Fuse etc type thing). That
way you can edit using local software and only write across the wire when you
save.

~~~
pavel_lishin
Many editors will periodically check for remote changes (especially when
switching away from and back to the editor) which can cause pretty annoying
slowdowns.

~~~
nailer
good point. I wonder if you can ask for notifications rather than checking for
changes (eg, inotify, fseventsd) remotely?

------
Famicoman
I do as much development in a local IDE as possible. From there I just depend
on git and ssh. Screen makes things a little more manageable as well.

~~~
filsmick
by 'depend on ssh', do you mean you ssh into the server and use a command-line
editor?

------
angdis
For when the shit really hits the fan... a terminal server connected to serial
port and remote power control for power cycling are indispensable.

------
nyamada
emacs + tramp + mosh + tmux

~~~
hapless
Tramp is outstandingly useful for remote editing tasks via ssh, telnet, ftp,
whatever.

It's "smarter" than sshfs/fuse, because tramp understands which files are
remote, and which are local.

------
filsmick
Thanks everyone for all the answers! It's really nice from you :)

------
valbaca
For Java: Samba share + IntelliJ For non-java: tmux+vim

------
dlsym
I use vim + tmux

------
ninebrows
vim + tmux

------
Avalaxy
I see no reason to develop on a server. If that's what you're doing, that's a
very bad sign in most of the cases.

~~~
scott_s
There is an enormous reason if you work on, or use, systems designed for
massive parallelism.

~~~
Avalaxy
I still don't see the necessity... Develop locally, test remotely.

~~~
ghgr
Some examples that just come to my mind:

\- You need software/dependendencies/licences you don't have in your local
machine.

\- You need to edit a config file (/etc/hosts or whatever) in your server

\- You are in a Windows computer (that's not yours) and you need to make a
quick change in your Ubuntu development server.

\- You need to edit some files when deploying (databases are no longer in
localhost, /home/myname/ is /home/servername/, etc.)

\- You launched a large script in your server and need to (view or parse logs
| edit the code and re-launch it | check why it didn't work)

\- etc.

~~~
joshka
software deps - this is a possible fair point. I've always managed to solve
this by bringing the deps local though as a general sanity rule. config - why
not source control it? quick change - why would you do a quick change
differently to a non-quick change? edit while deploying - why wouldn't you
script / source control this for repeatability / maintainability? log parsing
- it sounds like you've got an edit, verify loop going on. Why wouldn't you
want to formalize this so that you can see which changes align with which
results?

------
antocv
ssh, tmux, vim, git, more ssh, python, bash.

Depends on project, if it is JavaEE app, or Android, then you're screwed and
might as well work on a local version, because you need IntelliJ.

