Skip to content
A Heroku app for compiling Arduino sketches in the cloud
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
sketches @ e82fc77

Arduino Compiler

An Arduino web compiler (a thin wrapper around the arduino executable)

Local dependencies


$ brew install mongodb rabbitmq
$ brew services start mongodb
$ brew services start rabbitmq
$ npm install


  1. npm start
  2. http://localhost:5000


Clone locally and then deploy through the heroku CLI:

git clone
cd arduino-compiler

heroku create

heroku addons:add mongohq
heroku addons:add cloudamqp

heroku config:set NODE_ENV=production
heroku config:set VIEW_CACHE=true
heroku config:set THRIFTY=true

git push heroku master
heroku open


Environment variables are mapped to a config object in lib/config.js. This provides reasonable defaults as well as a layer of generalization (process.env.MONGOHQ_URL => config.mongo_url).

You can locally override the defaults by adding variables to a .env file.


The app is separated into two tiers:

This enables horizontally scaling both web traffic and long-running jobs.

On Heroku

The default deploy configuration includes THRIFTY=true, which starts the app in single-dyno mode to avoid charges. With THRIFTY=true, the web process handles both http requests and queued jobs. Keep in mind that this is a specific setting for this app, as THRIFTY is not a standard Heroku configuration.

Of course, a production app should never run in a single instance or make users wait for worker processes. When you're ready to test in staging or deploy to production, you can scale beyond single-dyno mode:

heroku config:unset THRIFTY
heroku ps:scale web=2 worker=2


npm start runs node-foreman, which will check the Procfile and start a single web process and a single worker process.

To test that your app behaves correctly when clustered in multiple processes, you can specify process scales to node-forman and set CONCURRENCY=4 in a local .env file.


Writing maintainable Node apps is all about separating concerns into small, well-defined modules. This barebones app has three distinct components with their own responsibilities:


The business logic is all in lib/app. This module orchestrates and provides a facade for the underlying MongoDB database and the RabbitMQ job queue.


The user-facing portion of the project lies in lib/web. This module is responsible for providing an http interface and routing requests. It shows things and relies on an App instance to do things.


The background processes run through lib/worker. This module is tiny - it just instantiates an App instance to process the job queue.

You can’t perform that action at this time.