{"id":15501817,"url":"https://github.com/gadicc/wmd","last_synced_at":"2026-01-28T08:38:31.265Z","repository":{"id":14151358,"uuid":"16857109","full_name":"gadicc/wmd","owner":"gadicc","description":null,"archived":false,"fork":false,"pushed_at":"2016-05-20T09:55:51.000Z","size":588,"stargazers_count":5,"open_issues_count":1,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-06-10T01:04:12.634Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/gadicc.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2014-02-15T05:18:18.000Z","updated_at":"2020-05-08T21:02:38.000Z","dependencies_parsed_at":"2022-07-08T03:57:52.016Z","dependency_job_id":null,"html_url":"https://github.com/gadicc/wmd","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/gadicc/wmd","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gadicc%2Fwmd","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gadicc%2Fwmd/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gadicc%2Fwmd/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gadicc%2Fwmd/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/gadicc","download_url":"https://codeload.github.com/gadicc/wmd/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gadicc%2Fwmd/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28842868,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-28T07:39:25.367Z","status":"ssl_error","status_checked_at":"2026-01-28T07:39:24.487Z","response_time":57,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-02T09:05:56.010Z","updated_at":"2026-01-28T08:38:31.250Z","avatar_url":"https://github.com/gadicc.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Wastelands Meteor Deployer\n\n\"Deploy Meteor with Meteor\".  A web interface to bring up new cloud\nservers, handle deployments (via github), load-balance,\nscale-on-demand, etc.  A work in progress.\n\nMeant to handle private code.  You run your own WMP server for all\nyour own projects.  This is not intended to be cloud-hosted and offer\ndeployment services to others (which is against the license).\nPLEASE READ \"IMPORTANT NOTES\", BELOW.\n\nCopyright (c) 2014 Gadi Cohen, see license below.\n\n## Features (implemented)\n\n* Create new cloud servers on demand.  With realtime stats.\n* Each Meteor process is run under forever-monitor, restarted\nautomatically, with realtime logs \u0026 stats on the Web UI.\n* Meteor is run directly, no bundling involved, for faster deploys\n\u0026 ultimate node compatibility (see FAQ).\n* Deployments are via github (see FAQ), with auto update on\na git push.\n* Nginx serves as a load balancer / reverse proxy in front of all\nyour Meteor instances, with integrated vhost and SSL management\nvia web UI.  Preconfigured for WebSockets and best caching policy\nto minimize load on Meteor (cache policy coming soon).\n\n## Features (coming soon)\n\n* Multi-tenancy.  Spawn a bigger spec machine and put as many of\nyour apps on it as you want, pooling resources.  Move the apps to\ntheir own / seperate servers only once the need arises.  Moving is\ndone with zero downtime.\n* Rules for when to spawn new servers, move Meteor to other servers, grow\nservers, etc.  During a move, the old process stays up until the new one\nis removed, for zero downtime.\n* Mongo management (with oplog, duh).  Support for multi-region databases.\n* Automated mongo backups (schedule, before upgrade, etc)\n* Extensions for e.g. email/sms/call if app goes down, etc.\n* Use private-IPs if available.\n\n## Quick start\n\n```bash\n$ git clone https://github.com/gadicohen/wmd.git\n$ cd wmd/server\n$ meteor\n```\n\nOpen browser, (setup and) login with Github, and explore.\n\nIf you're behind a NAT, make sure your Meteor port is properly\nforwarded, and, in JavaScript console, run `config.set('dyndnsHost', 'YOURHOST.dyndns.org')`;  It will be used as the hostname for ddp\nconnections from cloud servers if ROOT_URL contains `localhost`.\n\n## IMPORTANT NOTES\n\nNB: This is a work in progress.  You should only be using this in\ndevelopment on your home PC.  Few security checks are in place.  Error\nhandling is limited.\n\nSuper NB: For anything important (i.e., nothing you should be doing\nnow), use with force-ssl.  Github OAuth tokens are sent over the wire\nto your deployed servers.  Unless everything is over SSL, when you\nfinish playing, you should go to https://github.com/settings/applications,\nselect WMD, and click on 'Revoke all user tokens'.  (Your client\nsecret is ok).  OAuth tokens are not stored on any of your spawned\nservers.\n\nIt's entirely possible I may abandon this project entirely once\nGalaxy is launched.\n\nDISCLAIMER: Use at your own risk.  You are giving the app full access\nto your entire github codebase, and the ability to deploy new cloud\nservers which will COST YOU MONEY.  By using this code you agree that\nyou understand, and take responsibility for, all risks.\n\nLICENSE: [Ms-SS](http://directory.fsf.org/wiki/License:Ms-SS)\n(for now :)).  Open source for non-commercial use.\nTo be clear, companies may use the code freely under the license,\nthey simply cannot charge for the use of the product, i.e. the\nlicense probibits using the code, or modifications of the code,\nto operate a paid deployment service for end-users.\n\n## Preview Announcement\n\nWeb UI to deploy Meteor apps, including creation and setting up of\nnew cloud servers (on Digital Ocean), with realtime server and app\nresource monitoring, and automatic app updates after a github push.\n\nThis is a total preview meant for development use; notably there is\nnot much security in place yet (anyone can login and modify your apps).\nAlthough, when it is ready for production, it's kinda cool that you\ncan use the app to deploy itself (TODO, auto replicate database).\n\nIt started off as a project just for us internally, hence choice of\njust Digital Ocean and github.  But later on in the project, I've\ngradually started moving these things into seperate packages, so\nit could be easy to extend to other Amazon and other IaaS, bitbucket,\netc.\n\nA reminder: Digital Ocean servers are as little as $5/mo, but\nbilled per hour.  I spent less than $1 in total for all the time\nneeded to develop this app :)\n\n## FAQ\n\n* **Why just Digital Ocena and GitHub?**\n\nWMD was developed internally for our own use, and this is what we\nuse.  However, later we decided to make the design more modular,\nthe above are now both individually packaged plugins, and it should\nbe able to make a plugin for almost anything (Amazon, BitBucket,\netc).\n\n* **Why run in Meteor and send full source rather than bundling?**\n\nQuicker redeploy times.  A bundle on our big project takes 27s\nseconds to generate, and then still extract again (1s :)).  It's\ntrue Meteor has to minify/compile everything on startup, but after\nthis, on redeploys, only for changed files.  Overall that was much,\nmuch quicker for us (and no need to retransfer entire bundle).\n\nOther advantages include the fact that we get Meteor's recommended\n(and sometimes custom) node version, which can include patches\nahead of what's easily available / installable.\n\n* **How are git deployments done?**\n\nCurrently, a git pull is run on every server.  Long term, we'd\nprefer to git pull to the control server, and then in parallel,\nrsync (over SSH) to all the servers.  Think (hypothetically)\n200 servers in the same data center.  This should still remain\nan option for the case where control server is on dev's home\nPC, or servers are in multiple data centers.\n\n* **How does wmd-client work and authenticate itself?**\n\nWhen WMD creates a new server, it installs wmd-client on it.\nThere is no way to connect to the client, the client simply\nrepeatedly tries to open a DDP connection to wmd-server.\nServers are added as Meteor users; this allowed rapid\ndevelopment by leveraging Meteor's SRP implementation and \nDDP authentication.  In the future, we want to add a\ntwo-way authentication, situations where a fake server\ncould potentially hijack DNS (probably safer to use an IP),\nor other methods.  Note, even though the client password\nisn't sent in plaintext (thanks to SRP), plenty of sensitive\ninfo is sent over the wire (like Github OAuth tokens); as\nsuch, you server should be set up with SSL and force-ssl.\n\n* **What happens if the controller (wmd-server) is down?**\n\nAll created servers are fully self functioning (and reboot\nsafe!).  Nginx will notice if a server/app is crashing and\nremove it from the pool, but wmd-server won't notice this\nand won't spawn new servers (or once resource limit flags\nare reached according to rules).  Obviously, you won't be\nable to manually start/stop apps, adjust vhost config, etc.\n\n* **I think my database was compromised, what to do?**\n\n1. Revoke all Github user keys [here](https://github.com/settings/applications).\n1. Destroy all servers and dump the database (or give all servers new\npasswords in both the database and on your servers, gen new SSH key\npair and replace in database and on all servers and on DigitalOcean\ncontrol panel).\n1. Delete DigitalOcean OAuth pair on their Control Panel.\n1. Revoke all SSL certificates (not that it's\n[that effective](http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html) and create new ones \nfor all your domains.\n\nIn theory we could automate most of the above for this eventuality,\nor have regular rotations for extra security, or something.\n\n\n## Load testing Questions\n\nhttps://github.com/alanning/meteor-load-test\n\n1. How many concurrent users on each set of typical server specs?\nUntil significant speed loss, until melt down.\n1. Algorithm for rough estimation of how many users per *x* servers,\nwith standard setup (load balancer, nginx for static assets, seperate\ndb servers, etc).\n1. Automate testing of isolated differing approaches for same goal,\ne.g. optimization of publications, etc.  CPU, time, etc.\n\n## wmd.json (per app in root dir, all params optional.  TODO)\n\n{\n\tname:\n\tmeteorDir:\n\tinstances: {\n\t\tmin:\n\t\tmax:\n\t}\n}\n\n## Relevant Digital Ocean \"ideas\" to vote for!\n\n* [Deploy to physically seperated hardware](https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3859618-deploy-to-physically-separated-hardware) - so that if a DO server dies, it will take down\nat most, one of your instances (currently 1,190 votes, marked as\n\"planned\" for end of Q1 2014).\n\n* [movable IP from VM to VM (\"elastic IP\")](https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/2993170-movable-ip-from-vm-to-vm-elastic-ip-) - currently if your load balancer is down, all your sites\nare down.  No way to have a secondary/backup (currently 834 votes,\nmarked as \"planned\")\n\n* Private IPs are implemented [only in NYC2](https://www.digitalocean.com/blog_posts/introducing-private-networking) so far\n\n## Differences between Galaxy / Meteor.Com\n\nGalaxy is a commercially backed venture, maintained by the creators\nof Meteor (i.e. the Meteor experts), which handles everthing\ndeployment related for you (so you don't have to), and has an SLA\nguaranteeing uptime.\n\nWMD is an open source developer tool maintained by the community.\nIt explicity offers no guarantees and has a very liberal disclaimer.\nIt involves more work, more responsibility, but if you're reading\nthis, you probably understand this and you have your reasons for\nwanting to manage your own deployments.\n\nParticularly, vs current non-Galaxy Meteor.com deploys, WMD lets\nyou have SSL on custom domains, and oplog support.  These issues\nof course are addressed on Galaxy.\n\nReasons for wanting your own deployments could include:\n\n* Security implications of hosting all your own infrastructure\n* More flexibly resource management (VMs with high CPU/RAM just\nfor your app)\n* More flexible software options -- you run your own servers and\ncan install native Linux software on them to be used by your app.\n* Load balancing and stress testing.\n* Data center placement, e.g. Europe vs USA, etc.\n\nReasons to avoid this package and use Galaxy:\n\n* You want your deployments to be guaranteed by a commercial\ncompany with an SLA rather than loosely maintained scripts by the\ncommunity with no liability.\n* MDG developed Meteor, understand it better than anyone, and\nhave a team whose fulltime job it is to develop, test and maintain\nthe Galaxy infrastructure.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgadicc%2Fwmd","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgadicc%2Fwmd","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgadicc%2Fwmd/lists"}