How CodePicnic saved my friends’ job

I love coding. It’s the most rewarding thing I’ve ever done (building LEGO sets is in second place but I’ll talk about it another time). So, on weekends I like to help friends to solve problems with their websites.

This weekend I helped a couple of friends with a website made in Symfony. Their client hired them to do several changes, from front-end to back-end, and at this point, the project had been on so many hands that it was impossible to tell how it was set up. The thing is, the project was already overdue, none of us knew how to set up the development environment in order to get to work and the clock was ticking.

Now, I used to work with PHP so I had some experience with Apache and the like, but I am complete noob with Symfony, however I accepted to help them because it was an interesting challenge. Also, it was the perfect occasion to try the CodePicnic CLI, a tool our team at CodePicnic made to use our remote machines locally. Just think about Dropbox for code and it’s pretty much what we do.

So, first thing I had to do was check historyto see which commands were used to set up the app in production. Then, I had to check the PHP configuration (pretty much standard) and the MySQL database. Until this point, it was simple.

After creating a Git repo and setting up in the production server (did I mention the app wasn’t on any kind of version control and the deploys were made using FTP?) I realized I hadn’t used PHP in almost a decade and I didn’t have a proper environment to work with the app. But instead of checking which version of PHP or MySQL needed in local and install them, I decided to use CodePicnic. After all, dogfooding is some thing a SaaS have to do.

With CodePicnic CLI I can work with a MySQL database remotely.

CodePicnic CLI has two commands which I think are essential if you want to try the full potential of CodePicnic: codepicnic connect and codepicnic mount. With codepicnic connect you can start a Bash session inside a CodePicnic console and start services, like Apache o MySQL, and with codepicnic mount you can mount a console’s working directory in your local computer and use any code editor you want.

Before using the CLI I needed to create the actual console where I was going to work. I picked the right version of PHP I needed and that was it.

Below each console in our Dashboard we show its ID, which is the way we identify our consoles in the CLI. Then, the next step is downloading the CLI, put your CodePicnic credentials and start working.

After connecting to the console I cloned the project’s repo and started installing the dependencies. I found the cURL extension wasn’t available so I installed with apt-get install php5-curl. Then, I needed to create a dump from the MySQL database in the production server and copy the file from the server to my console with mysqldump and scp. After creating the MySQL user and granting it with permissions over the newly imported database, I was ready to start the app (and my work).

But it wasn’t so easy. I thought I needed to use php bin/console server:run to serve the app, but it didn’t worked as expected. After thinking for a while I realized that maybe the app wasn’t being served using Symfony commands (after all, I didn’t see server:run in history). So I had to symlink my working directory with /var/www, because the production server was configured to serve the app through Apache. After that, I finally could work on the project.

Using codepicnic mount I can work with remote files locally. Think about Dropbox for code.

With my environment ready to be used I needed to start working on the project’s codebase, but coding in a browser for hours is not something I really am up to. Lucky for me, CodePicnic CLI had the answer for this.

With codepicnic mount I can mount my console’s filesystem on my local computer and work with the files with any editor I want. All the changes are automatically synced in the console’s remote filesystem and I can see the results in a special URL provided by the console. Having worked with documents using Dropbox or Google Docs apps, this approach is definitely my favorite when I have to deal with remote files.

So now I can work with my Symfony console using Visual Studio Code instead of using CodePicnic web app. Using my favorite tools not only is comfortable but increases my productivity.

I’ve been working this way for a complete weekend and I finished already half of the job. I didn’t need to install anything on my computer, or dealing (and messing up) my own settings. Not only this, but I shared my console with my friends so they don’t have to go through the painful path of dealing with strange configurations. Even we don’t have the CLI, we can work in my Symfony console using the collaborative mode through the browser, but the CLI is really a game changer.


In CodePicnic we want to reduce set up times by offering a wide selection of consoles with languages and frameworks already installed, so us developers can try new code base in matter of minutes instead of hours. This way, not only time barriers are dropped, but less resources are used to start learning new languages, frameworks or tools. With the CLI I truly believe we are moving on the (right) direction.