# remote-development Published articles for remote-development. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The Evolution of WSL Support in JetBrains IDEs DevFeed: [The Evolution of WSL Support in JetBrains IDEs]() Original publisher: [Read original article]() Author: Kristina Pchelintseva Published: 2026-09-09T10:39:49Z Content type: article Language: en Sources: [The JetBrains Blog]() Topics: [IntelliJ IDEA](), [Processes]() Tags: [2026-2](), [architecture](), [debug](), [ecosystem](), [engineering](), [ide](), [idea](), [intellij-idea](), [intellij-platform](), [linux](), [phpstorm](), [remote-development](), [support](), [webstorm](), [windows](), [wsl]() ### AI overview JetBrains describes its evolution of WSL integration and recommends Native mode from version 2026.2. In this mode, supported IDEs remain Windows applications while an agent in WSL handles project files and processes. ### Source excerpt JetBrains IDEs have worked with WSL for many years, and over time, several ways of using it have emerged across our products. Depending on the entry point, the IDE could rely on a different underlying architecture, leading to a different experience. Starting with the 2026.2 release, there is one recommended entry point. In IntelliJ IDEA, [...] ## Run Codex in the cloud - DigitalOcean for Codex is now available DevFeed: [Run Codex in the cloud - DigitalOcean for Codex is now available]() Original publisher: [Read original article]() Author: Ari Sigal Published: 2026-06-25T21:16:06Z Content type: release Language: en Sources: [DigitalOcean]() Topics: [codex](), [Digital Ocean](), [remote-development](), [Cloud](), [Provisioning](), [ssh](), [ChatGPT]() Tags: [ai-ml](), [cloud](), [codex](), [digitalocean](), [mobile](), [oauth](), [plugin](), [preview](), [product-updates](), [provisioning](), [remote-development](), [ssh]() ### AI overview DigitalOcean announces a Public Preview plugin for Codex that lets developers provision persistent, Codex-ready cloud development machines in their own DigitalOcean accounts using natural-language prompts. The resulting Droplets include the Codex CLI, common programming-language tooling, and SSH access. ### Source excerpt As your agents are working on more complex, long-running work, they need a clean, persistent environment to keep running. Setting up a persistent remote machine by hand means creating a cloud server, configuring SSH keys, installing dependencies, and wiring everything back to your workflow. It's a lot of infrastructure work before you write a single line of code. Today, we're making that easier. The DigitalOcean plugin for Codex is now available in Public Preview, letting developers create and connect Codex-ready cloud development machines in their own DigitalOcean account directly from within Codex -- using natural language, with no manual setup. This means that not only can your work continue running when you step away, but with Codex in the ChatGPT mobile app you can stay in control -- starting, steering, or monitoring work from wherever you are. What is DigitalOcean for Codex? The DigitalOcean plugin connects your DigitalOcean account to the Codex app, letting you provision a persistent remote development environment on demand. Instead of manually spinning up a server and configuring it, you can ask Codex to do it. The result: a DigitalOcean Droplet® that's pre-configured with the Codex CLI, common programming language tooling (based on the codex-universal Docker image), and SSH access -- so your work can keep running and stay within reach, even when you're not at your desk. How it works Starting from Codex Install the DigitalOcean plugin from the Codex plugin directory. During installation, you'll connect your DigitalOcean account via OAuth -- no API tokens to create or paste. Then prompt: @DigitalOcean create a new remote machine Codex will: Provision a new Droplet from the Codex Droplet template Generate and configure an SSH key on your device Wait for the machine to finish provisioning (and check back automatically when it's ready) Return a deeplink to the Codex SSH connections page to finalize the connection Once connected, you're running Codex on a persistent ## A Deep Dive into My Remote Development Setup DevFeed: [A Deep Dive into My Remote Development Setup]() Original publisher: [Read original article]() Author: Kevin Naughton Jr. Published: 2026-04-19T16:01:58Z Content type: article Language: en Sources: [The Software Engineer Weekly]() Topics: [remote-development](), [Cloud](), [Development]() Tags: [cloud](), [development](), [remote](), [remote-development](), [workflow]() ### AI overview This article discusses the rationale for moving an entire development workflow to the cloud and treating a laptop as a disposable rather than precious asset. ### Source excerpt Last week, I talked about the philosophy of "Cattle, Not Pets", the idea that your laptop should be disposable, not a precious asset. But why actually go through the trouble of moving your entire workflow to the cloud? ## Zed Adds Remote Development Over SSH DevFeed: [Zed Adds Remote Development Over SSH]() Original publisher: [Read original article]() Author: Conrad Irwin Published: 2024-10-30T00:00:00Z Content type: article Language: en Sources: [Zed Industries - Blog]() Topics: [remote-development](), [ssh](), [Development]() Tags: [architecture](), [cloud](), [collaboration](), [development](), [linux](), [machine](), [projects](), [protocol](), [rebuilds](), [remote](), [remote-development](), [server](), [ssh](), [synchronization](), [tests]() ### AI overview Zed adds remote development over SSH, keeping the user interface local while running language servers, tasks, and terminals on the remote machine. The article explains connection maintenance, remote server installation and compatibility, reconnection behavior, local backups, and collaboration support. ### Source excerpt Zed can now be used to edit over SSH. ## Evolution of Developer Productivity at Square - Part Two DevFeed: [Evolution of Developer Productivity at Square - Part Two]() Original publisher: [Read original article]() Author: Korhan Bircan Published: 2024-01-29T09:00:00Z Content type: article Language: en Sources: [Square Corner Blog](), [Square Corner Blog RSS Feed]() Topics: [code productivity](), [build times](), [Android](), [remote-development](), [Continuous integration](), [Optimization](), [Caching](), [Gradle](), [Amazon EC2](), [ide](), [benchmarking]() Tags: [android](), [benchmarking](), [build-times](), [caching](), [cloud](), [continuous-integration](), [developer-productivity](), [development](), [engineering](), [gradle](), [ide](), [optimization](), [remote-development](), [velocity]() ### AI overview Square describes efforts to improve developer productivity and development velocity by reducing build, installation, IDE synchronization, and continuous integration times. The article reports development apps, remote Android development environments, configuration caching, CI shard skipping, emulator optimization, Gradle changes, and modularization work. ### Source excerpt Accelerating development velocity ## Zed Weekly: Channel Chat, Semantic Index Updates, Prettier Integration, and Autocomplete Docs DevFeed: [Zed Weekly: Channel Chat, Semantic Index Updates, Prettier Integration, and Autocomplete Docs]() Original publisher: [Read original article]() Author: Mikayla Maki Published: 2023-09-18T00:00:00Z Content type: article Language: en Sources: [Zed Industries - Blog]() Topics: [Development](), [Prettier](), [AI search](), [Artificial Intelligence](), [remote-development]() Tags: [autocomplete](), [chat](), [code](), [docs](), [formatting](), [integration](), [remote-development](), [search](), [testing](), [weekly]() ### AI overview This weekly development update covers progress on Zed's channel chat system, a moving and linking channels project, fixes for hint and LSP status bugs, and local Prettier integration. It also reports Semantic Index support for modified open buffers, an evaluation framework for the engine, planned integration with the inline code assistant, and continued autocomplete documentation work. ### Source excerpt Shipping channel chat, GPUI2 code samples, and autocomplete docs, and adding replace to our buffer search! ## Bringing Postgres to Bunnyshell with Neon DevFeed: [Bringing Postgres to Bunnyshell with Neon]() Original publisher: [Read original article]() Author: Nikita Shamgunov Published: 2023-03-30T13:38:29Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [Developer Platform](), [Databases](), [remote-development](), [Database](), [Provisioning](), [Testing]() Tags: [case-studies](), [cloud](), [core](), [database](), [databases](), [developer-platform](), [development](), [productivity](), [provisioning](), [remote-development](), [testing]() ### AI overview Bunnyshell integrates Neon Postgres into its cloud-first Environment-as-a-Service platform, enabling on-demand development environments and ephemeral staging and QA environments. Neon provides near-instant provisioning, populated databases, branching for isolated production-like databases, and automatic scaling for short-lived environments. ### Source excerpt Bunnyshell is a cloud-first developer platform that enables teams to effortlessly create on-demand environments for development, as well as ephemeral environments for staging and QA. Their platform enables engineering teams to focus on building core product features rather than s... ## Remote Software Development - Lessons Learned DevFeed: [Remote Software Development - Lessons Learned]() Original publisher: [Read original article]() Author: umer Published: 2016-06-12T00:00:00Z Content type: article Language: en Sources: [Code Ahoy - Articles]() Topics: [remote-development](), [Development](), [Code](), [modules](), [Java]() Tags: [code](), [java](), [modules](), [remote](), [remote-development](), [software-development]() ### AI overview The author describes lessons from building a remote software development team while working on a replacement for a rejected product system. Tightly coupled code and poorly isolated modules made independent work, onboarding remote developers, and integration difficult. ### Source excerpt Previously, I talked about the ill-fated rewrite of our core product. The 'second system', although better and faster than its predecessor, was rejected by the customer. But the story has a silver lining - one thing that we got right in the process that empowered us to grow and thrive: we built a highly productive remote development team. In this post, I'll share my experiences: how through trial and error (and with luck), we finally got the right formula and made it work for us. Part of the original system team was one of the best duct-tape developers I've ever worked with. We called him 'The Code Machine'. He didn't write clean code, but he wrote it fast as hell and made sure it worked. The original system, done with a gun to our heads, was a big, complex, monolith application and the boundaries between its modules were ill defined. Computer scientists refer to this type of code as tightly-coupled and the system is referred to as non-orthogonal. The 'second system' had a more grand vision and we needed to grow the team to build it right and on schedule. We hired another developer, a bright, young CS graduate to work on the system. One problem with the original system quickly became evident to me: because the code was tightly-coupled (the auto-generated UML class diagrams resembled a spider's cobweb), the new developer couldn't work independently: changing one part of the system indirectly impacted other parts. While they were not bickering, the two developers couldn't get out of each other's way and the progress was slow. Parallel to all this, the upper management decided to give 'remote software development' a try. Someone on the board recommended a company from Hyderabad, India and before I even knew it, I was interviewing a bunch of remote Java developers. The non-orthogonality problem was further magnified when the remote developer joined the team. Because the system was tightly-coupled, he was going to have to learn it all before he could become productive. S