|
| 1 | +--- |
| 2 | +title: Remote Applications |
| 3 | +description: Dockerized applications can run remotely and feel native on your system. By combining them with simple aliases, you can make these tools behave like local apps while actually being powered from the cloud. |
| 4 | +date: 2025-09-16 |
| 5 | +draft: false |
| 6 | +toc: true |
| 7 | +ShowLastmod: true |
| 8 | +--- |
| 9 | + |
| 10 | +## What Are Remote Apps? |
| 11 | + |
| 12 | +In the traditional software world, installing an application meant dealing with dependencies, OS differences, or compatibility issues. But modern computing gives us a better option: **remote applications**. |
| 13 | + |
| 14 | +By "remote," I mean apps that are not tied to your local machine but instead run through **Docker containers**. With Docker, you no longer care whether you’re on Ubuntu, Fedora, macOS, or even Windows—if Docker runs there, the app runs there. |
| 15 | + |
| 16 | +The difference is: instead of thinking of them as "local installs," you start treating them as **on-demand tools** that live in the cloud or on a server. |
| 17 | + |
| 18 | +This approach unlocks **portability**, **reliability**, and **ease of use** across environments. |
| 19 | + |
| 20 | +--- |
| 21 | + |
| 22 | +## A Practical Example: Oxker |
| 23 | + |
| 24 | +Take [Oxker](https://github.com/mrjackwills/oxker), a simple TUI that displays Docker containers on your machine. To run it, they provide a one-liner: |
| 25 | + |
| 26 | +```bash |
| 27 | +docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock:ro --pull=always mrjackwills/oxker |
| 28 | +``` |
| 29 | +This is great—it spins up Oxker instantly, always with the latest version. But typing this every time? Not very friendly. |
| 30 | + |
| 31 | +Instead, imagine simply running: |
| 32 | +```bash |
| 33 | +oxker |
| 34 | +``` |
| 35 | +That feels like a **native application**, even though it’s actually a **remote container**. Smooth, minimal, and intuitive. |
| 36 | + |
| 37 | +--- |
| 38 | + |
| 39 | +## The Power of Aliases |
| 40 | + |
| 41 | +This magic happens through something as simple as a Linux [alias](https://phoenixnap.com/kb/linux-alias-command). By creating an alias that maps `oxker` to the full `docker run` command, you get the best of both worlds: |
| 42 | + |
| 43 | +- No installation headaches |
| 44 | +- Always up to date (since it pulls the latest container) |
| 45 | +- Works anywhere Docker runs |
| 46 | +- Feels like a real, local command |
| 47 | +- |
| 48 | +This is a small trick, but it changes your workflow dramatically. Suddenly, remote containerized apps behave like first-class citizens on your machine. |
| 49 | + |
| 50 | +--- |
| 51 | + |
| 52 | +## How to Set Up Aliases for Remote Apps |
| 53 | + |
| 54 | +Here’s how you can turn any Docker command into a native-feeling app: |
| 55 | + |
| 56 | +1. **Open your shell configuration file** (depending on what you use): |
| 57 | + - For Bash: |
| 58 | +```bash |
| 59 | + nano ~/.bashrc |
| 60 | +``` |
| 61 | + - For Zsh: |
| 62 | +```bash |
| 63 | + nano ~/.zshrc |
| 64 | +``` |
| 65 | + |
| 66 | +2. **Add an alias for your Dockerized app.** For Oxker, paste: |
| 67 | + ```bash |
| 68 | + alias oxker="docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock:ro --pull=always mrjackwills/oxker" |
| 69 | + ``` |
| 70 | + |
| 71 | +3. **Apply the changes** without restarting: |
| 72 | + ```bash |
| 73 | + source ~/.bashrc |
| 74 | + # or for Zsh |
| 75 | + source ~/.zshrc |
| 76 | + ``` |
| 77 | + |
| 78 | +4. **Run it just like a native app:** |
| 79 | + ```bash |
| 80 | + oxker |
| 81 | + ``` |
| 82 | + |
| 83 | +That’s it! You’ve created a remote app experience. |
| 84 | + |
| 85 | +--- |
| 86 | + |
| 87 | +## Why This Matters |
| 88 | + |
| 89 | +Think about the implications: |
| 90 | + |
| 91 | +- **Lightweight Device Support** |
| 92 | + Have a weaker laptop and don't want to download apps No problem. Let a server host the applications, while your device just runs containers from server. |
| 93 | + |
| 94 | +- **No More Setup Hell** |
| 95 | + How many times have you wasted hours setting up dev tools or debugging dependencies? With remote apps, you bypass all of that. |
| 96 | + |
| 97 | +- **Collaboration Made Simple** |
| 98 | + You don’t even need your own server. Publish the container to Docker Hub, and anyone can run the exact same version instantly. Consistency for teams, zero friction for users. |
| 99 | + |
| 100 | +
|
| 101 | +This is not just about convenience—it’s a **paradigm shift in how we think about software distribution**. |
| 102 | +
|
| 103 | +--- |
| 104 | +
|
| 105 | +## The Downsides of Remote Apps |
| 106 | +
|
| 107 | +As powerful as remote applications are, they do come with trade-offs worth keeping in mind: |
| 108 | +
|
| 109 | +- **Performance Overhead** |
| 110 | + Running apps in Docker and pulling them on-demand is not as fast as having them installed natively. For heavy tools, this can mean longer startup times. |
| 111 | +- **Network Dependency** |
| 112 | + If your alias depends on pulling images from Docker Hub or another registry, you need a stable internet connection. Offline use is limited unless you cache the images locally. |
| 113 | +- **Storage Usage** |
| 114 | + Each image still takes up disk space after the first pull. Over time, unused containers and images can clutter your system if you don’t prune them. |
| 115 | +- **Security Considerations** |
| 116 | + Running third-party containers always carries some risk. You need to trust the publisher or audit the Dockerfile to ensure the container is safe. |
| 117 | +- **Learning Curve** |
| 118 | + For people new to Docker, the setup can feel unfamiliar compared to a simple `apt install` or `brew install`. While aliases simplify usage, the underlying concepts still require some understanding. |
| 119 | +
|
| 120 | +but I'm sure there is many use cases for this kind of setup. |
| 121 | + |
| 122 | +--- |
| 123 | + |
| 124 | +## The Future of Remote Apps |
| 125 | + |
| 126 | +I believe this should be the standard way we think about applications: **remote, containerized, and alias-driven**. |
| 127 | + |
| 128 | +Instead of bloating our systems with installs and configs, we can adopt a lightweight, cloud-first approach: |
| 129 | + |
| 130 | +- Define apps as containers |
| 131 | +- Publish them for universal access |
| 132 | +- Alias them into our local workflow |
| 133 | + |
| 134 | +The end result? A system where your local machine feels infinite, powered by remote applications. |
| 135 | + |
| 136 | +--- |
| 137 | + |
| 138 | +## Final Thoughts |
| 139 | + |
| 140 | +Remote applications are not just a technical trick—they represent a **new mindset**: |
| 141 | + |
| 142 | +- Apps that run anywhere |
| 143 | +- Apps that are always up-to-date |
| 144 | +- Apps that feel local, but are powered remotely |
| 145 | + |
| 146 | +If you start adopting this approach in your workflow, you’ll notice how much friction disappears. Suddenly, your environment is cleaner, your setup is faster, and your tools are more reliable. |
| 147 | + |
| 148 | +It’s not just about saving keystrokes. It’s about **building a future where software is portable, accessible, and remote by default.** |
0 commit comments