+
+ | Type |
+ Taal |
+ Library |
+ Adapters |
+
+
+ | Database |
+ Ruby/Rails |
+ ActiveRecord |
+ MySQL, PostgreSQL, SQLite |
+
+
+ | Queue |
+ Python/Django |
+ Celery |
+ RabbitMQ, Beanstalkd, Redis |
+
+
+ | Cache |
+ Ruby/Rails |
+ ActiveSupport::Cache |
+ Geheugen, bestandssysteem, Memcached |
+
+
+
+Ontwikkelaars vinden het soms erg aantrekkelijk om een lichtgewicht backing service te gebruiken in hun lokale omgevingen, terwijl een serieuzere en robuustere backing service zal worden gebruikt in productie. Bijvoorbeeld, het gebruik van SQLite lokaal en PostgreSQL in productie; of lokaal procesgeheugen voor caching in ontwikkeling en Memcached in productie.
+
+**De 12-factor ontwikkelaar weerstaat de drang om verschillende backing services te gebruiken tussen ontwikkeling en productie**, zelfs wanneer adapters theoretisch alle verschillen in backing services wegnemen. Verschillen tussen backing services betekenen dat kleine incompatibiliteiten opduiken, waardoor code die werkte en tests doorstond in ontwikkeling of staging, faalt in productie. Dit soort fouten creëert wrijving die continue implementatie ontmoedigt. De kosten van deze wrijving en de daaropvolgende afremming van continuous deployment zijn extreem hoog als je ze over de levensduur van een applicatie bij elkaar optelt.
+
+Lichtgewicht lokale diensten zijn minder aantrekkelijk dan ze ooit waren. Moderne backing services zoals Memcached, PostgreSQL, en RabbitMQ zijn niet moeilijk te installeren en te draaien dankzij moderne packaging systemen, zoals [Homebrew](http://mxcl.github.com/homebrew/) en [apt-get](https://help.ubuntu.com/community/AptGet/Howto). Als alternatief stellen declaratieve provisioning tools zoals [Chef](http://www.opscode.com/chef/) en [Puppet](http://docs.puppetlabs.com/) in combinatie met lichtgewicht virtuele omgevingen zoals [Docker](https://www.docker.com/) en [Vagrant](http://vagrantup.com/) ontwikkelaars in staat om lokale omgevingen te draaien die productieomgevingen dicht benaderen. De moeite van installatie en gebruik van deze systemen zijn laag vergeleken met het voordeel van dev/prod pariteit en continue deployment.
+
+Adapters voor verschillende backing services zijn nog steeds nuttig, omdat ze het porten naar nieuwe backing services relatief pijnloos maken. Maar alle deploys van de app (ontwikkelomgevingen, staging, productie) zouden hetzelfde type en dezelfde versie van elk van de backing services moeten gebruiken.
\ No newline at end of file
diff --git a/content/nl/disposability.md b/content/nl/disposability.md
new file mode 100644
index 000000000..e63233e6f
--- /dev/null
+++ b/content/nl/disposability.md
@@ -0,0 +1,12 @@
+## IX. Wegwerpbaarheid
+### Maximaliseer robuustheid met snel opstarten en elegant afsluiten
+
+**De 12-factor app's [processen](./processen) zijn *wegwerpbaar*, wat betekent dat ze kunnen worden gestart of gestopt op elk moment.** Dit vergemakkelijkt snel elastisch schalen, snel implementeren van [code](./codebase) of [config](./config) veranderingen, en robuustheid van productie deploys.
+
+Processen moeten streven naar **minimale opstarttijd**. In het ideale geval heeft een proces een paar seconden nodig vanaf het moment dat het launch commando wordt uitgevoerd totdat het proces opgestart is en klaar om verzoeken of opdrachten te ontvangen. Een korte opstarttijd zorgt voor meer wendbaarheid voor het [release](./build-release-run) proces en het opschalen; en het bevordert de robuustheid, omdat het procesbeheerder processen gemakkelijker kan verplaatsen naar nieuwe fysieke machines wanneer dat gerechtvaardigd is.
+
+Processen **sluiten elegant af wanneer ze een [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** signaal ontvangen van de procesbeheerder. Voor een webproces wordt "graceful shutdown" bereikt door te stoppen met luisteren op de servicepoort (en daarbij nieuwe verzoeken te weigeren), alle lopende verzoeken te laten afwerken, en dan af te sluiten. Impliciet in dit model is dat HTTP-verzoeken kort zijn (niet meer dan een paar seconden), of in het geval van long polling, de cliënt moet probleemloos proberen opnieuw verbinding te maken wanneer de verbinding wordt verbroken.
+
+Voor een worker proces, wordt graceful shutdown bereikt door de huidige job terug te sturen naar de work queue. Bijvoorbeeld, op [RabbitMQ](http://www.rabbitmq.com/) kan de worker een [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack) sturen; op [Beanstalkd](https://beanstalkd.github.io), wordt de taak automatisch teruggegeven aan de wachtrij wanneer een worker de verbinding verbreekt. Lock-gebaseerde systemen zoals [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) moeten er zeker van zijn dat ze hun lock op het taakrecord vrijgeven. Impliciet in dit model is dat alle jobs [reentrant](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29) zijn, wat typisch wordt bereikt door de resultaten in een transactie te verpakken, of door de operatie [idempotent](http://en.wikipedia.org/wiki/Idempotence) te maken.
+
+Processen moeten ook **robuust zijn tegen plotse dood**, in het geval van een storing in de onderliggende hardware. Hoewel dit veel minder vaak voorkomt dan een "graceful shutdown" met `SIGTERM`, kan het nog steeds gebeuren. Een aanbevolen aanpak is het gebruik van een robuust queueing backend, zoals Beanstalkd, dat jobs teruggeeft aan de queue wanneer clients de verbinding verbreken of time-out gaan. Hoe dan ook, een 12-factor app is ontworpen om onverwachte, niet-gracieuze beëindigingen aan te kunnen. [Crash-only ontwerp](http://lwn.net/Articles/191059/) brengt dit concept naar zijn [logische conclusie](http://docs.couchdb.org/en/latest/intro/overview.html).
\ No newline at end of file
diff --git a/content/nl/intro.md b/content/nl/intro.md
new file mode 100644
index 000000000..5610186b8
--- /dev/null
+++ b/content/nl/intro.md
@@ -0,0 +1,12 @@
+Introductie
+============
+
+In het moderne tijdperk wordt software vaak geleverd als een dienst: *web apps* genaamd, of *software-as-a-service*. De twelve-factor app is een methodologie voor het bouwen van *software-as-a-service* die:
+
+* Gebruik maakt van **delcaratieve** formaten voor geautomatiseerde installatie, om tijd en kosten te minimaliseren voor nieuwe ontwikkelaars die zich bij het project aansluiten;
+* Een **clean contract** hebben met het onderliggende besturingssysteem, dat **maximale portabiliteit** aanbiedt tussen uitvoeringsomgevingen;
+* Geschikt zijn voor **implementatie** op moderne **cloud platforms**, met als gevolg de nood aan servers en systeembeheer overbodig te maken;
+* **Minimaliseren van verschillen** tussen ontwikkeling en productie, waardoor **continuous deployment** mogelijk is voor maximale wendbaarheid;
+* En kan **opgeschaald** worden zonder significante wijzigingen in tooling, architectuur of ontwikkelingspraktijken.
+
+De 12-factor methodologie kan worden toegepast op apps geschreven in elke programmeertaal, en die gebruik maken van elke combinatie van backing services (databases, queue, memory cache, etc).
\ No newline at end of file
diff --git a/content/nl/logs.md b/content/nl/logs.md
new file mode 100644
index 000000000..e3be5ecbb
--- /dev/null
+++ b/content/nl/logs.md
@@ -0,0 +1,16 @@
+## XI. Logs
+### Behandel logs als event streams
+
+*Logs* geven inzicht in het gedrag van een draaiende app. In server-gebaseerde omgevingen worden ze gewoonlijk naar een bestand op schijf geschreven (een "logfile"); maar dit is slechts een uitvoerformaat.
+
+Logs zijn de [stream](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) van geaggregeerde, tijdsgeordende gebeurtenissen verzameld uit de uitvoerstromen van alle draaiende processen en backing services. Logs in hun ruwe vorm zijn typisch een tekstformaat met één gebeurtenis per lijn (hoewel backtraces van uitzonderingen meerdere lijnen kunnen beslaan). Logs hebben geen vast begin of einde, maar stromen continu door zolang de app actief is.
+
+**Een 12-factor app houdt zich nooit bezig met het routeren of opslaan van zijn uitvoerstroom.** Hij moet niet proberen te schrijven naar logfiles of deze te beheren. In plaats daarvan schrijft elk draaiend proces zijn event stream, ongebufferd, naar `stdout`. Tijdens lokale ontwikkeling, zal de ontwikkelaar deze stroom op de voorgrond van zijn terminal bekijken om het gedrag van de app te observeren.
+
+In staging of productie implementaties, zal de stream van elk proces worden opgevangen door de executie omgeving, samengevoegd met alle andere streams van de app, en gerouteerd worden naar een of meer eindbestemmingen om te bekijken en op lange termijn te archiveren. Deze archiveringsbestemmingen zijn niet zichtbaar voor of configureerbaar door de app, en worden in plaats daarvan volledig beheerd door de executie-omgeving. Open-source logrouters (zoals [Logplex](https://github.com/heroku/logplex) en [Fluentd](https://github.com/fluent/fluentd)) zijn beschikbaar voor dit doel.
+
+De event stream voor een app kan worden gerouteerd naar een bestand, of worden bekeken via realtime tail in een terminal. Het belangrijkste is dat de stroom kan worden verzonden naar een logindexerings- en analysesysteem zoals [Splunk](http://www.splunk.com/), of een datawarehousing systeem voor algemene doeleinden zoals [Hadoop/Hive](http://hive.apache.org/). Deze systemen bieden een grote kracht en flexibiliteit voor het introspecteren van het gedrag van een app in de tijd, inclusief:
+
+* Het vinden van specifieke gebeurtenissen in het verleden.
+* Grafieken op grote schaal van trends (zoals verzoeken per minuut).
+* Actieve alarmering volgens door de gebruiker gedefinieerde heuristiek (zoals een waarschuwing wanneer het aantal fouten per minuut een bepaalde drempel overschrijdt).
\ No newline at end of file
diff --git a/content/nl/port-binding.md b/content/nl/port-binding.md
new file mode 100644
index 000000000..c579139d3
--- /dev/null
+++ b/content/nl/port-binding.md
@@ -0,0 +1,14 @@
+## VII. Poort-binding
+### Exporteer diensten via poort binding
+
+Web apps worden soms uitgevoerd binnen een webserver container. PHP apps kunnen bijvoorbeeld draaien als een module binnen [Apache HTTPD](http://httpd.apache.org/), of Java apps kunnen draaien binnen [Tomcat](http://tomcat.apache.org/).
+
+**De 12-factor app is volledig op zichzelf staand** en is niet afhankelijk van runtime injectie van een webserver in de uitvoeringsomgeving om een web-facing service te creëren. De web app **exporteert HTTP als een service door te binden aan een poort**, en te luisteren naar verzoeken die binnenkomen op die poort.
+
+In een lokale ontwikkelomgeving bezoekt de ontwikkelaar een service URL zoals `http://localhost:5000/` om toegang te krijgen tot de service die door zijn app wordt geëxporteerd. Bij de implementatie zorgt een routering laag voor het routeren van verzoeken van een publieke hostnaam naar de poort-gebonden web processen.
+
+Dit wordt typisch geïmplementeerd door gebruik te maken van [dependency declaration](./dependencies) om een webserver library toe te voegen aan de app, zoals [Tornado](http://www.tornadoweb.org/) voor Python, [Thin](http://code.macournoyer.com/thin/) voor Ruby, of [Jetty](http://www.eclipse.org/jetty/) voor Java en andere JVM-gebaseerde talen. Dit gebeurt volledig in *gebruikersruimte*, dat wil zeggen, binnen de code van de app. Het contract met de uitvoeringsomgeving is het binden aan een poort om verzoeken te serveren.
+
+HTTP is niet de enige dienst die kan worden geëxporteerd door poortbinding. Bijna elke soort server software kan worden uitgevoerd via een proces dat zich bindt aan een poort en wacht op inkomende verzoeken. Voorbeelden zijn [ejabberd](http://www.ejabberd.im/) (die [XMPP](http://xmpp.org/) aanspreekt), en [Redis](http://redis.io/) (die het [Redis protocol](http://redis.io/topics/protocol) aanspreekt).
+
+Merk ook op dat de port-binding aanpak betekent dat een app de [backing service](./backing-services) voor een andere app kan worden, door de URL naar de backing app als een resource handle in de [config](./config) voor de consumerende app op te geven.
\ No newline at end of file
diff --git a/content/nl/processes.md b/content/nl/processes.md
new file mode 100644
index 000000000..dfc4d3aa0
--- /dev/null
+++ b/content/nl/processes.md
@@ -0,0 +1,14 @@
+## VI. Processen
+### De app als één of meer stateloze processen uitvoeren
+
+De app wordt in de uitvoeringsomgeving uitgevoerd als een of meer *processen*.
+
+In het eenvoudigste geval is de code een stand-alone script, de uitvoeringsomgeving is de lokale laptop van een ontwikkelaar met een geïnstalleerde runtime, en het proces wordt gestart via de commandoregel (bijvoorbeeld `python my_script.py`). Aan de andere kant van het spectrum kan een productie-implementatie van een geavanceerde app gebruik maken van vele [procestypes, geïnstantieerd in nul of meer lopende processen](./concurrency).
+
+**12-factor processen zijn stateless en [delen-niets](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** Alle gegevens die moeten blijven bestaan, moeten worden opgeslagen in een stateful [backing service](./backing-services), meestal een database.
+
+De geheugenruimte of het bestandssysteem van het proces kan worden gebruikt als een korte, eenmalige transactie cache. Bijvoorbeeld het downloaden van een groot bestand, het bewerken ervan, en het opslaan van de resultaten van de operatie in de database. De 12-factor app gaat er nooit van uit dat iets wat in de cache of op de schijf zit, beschikbaar zal zijn voor een toekomstig verzoek of een toekomstige taak -- met veel processen van elk type die draaien, is de kans groot dat een toekomstig verzoek door een ander proces zal worden uitgevoerd. Zelfs als er maar één proces draait, zal een herstart (veroorzaakt door het implementeren van code, het wijzigen van de configuratie, of de uitvoeringsomgeving die het proces naar een andere fysieke locatie verplaatst) meestal alle lokale state wissen (bv. geheugen en bestandssysteem).
+
+Asset packagers zoals [django-assetpackager](http://code.google.com/p/django-assetpackager/) gebruiken het bestandssysteem als een cache voor gecompileerde assets. Een 12-factor app doet dit compileren het liefst tijdens de [build stage](/build-release-run). Asset packagers zoals [Jammit](http://documentcloud.github.com/jammit/) en de [Rails asset pipeline](http://ryanbigg.com/guides/asset_pipeline.html) kunnen worden geconfigureerd om assets te packagen tijdens de build stage.
+
+Sommige websystemen vertrouwen op ["sticky sessions"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) -- dat is het cachen van gebruikerssessiegegevens in het geheugen van het proces van de app en verwachten dat toekomstige verzoeken van dezelfde bezoeker naar hetzelfde proces worden gerouteerd. Sticky sessies zijn een schending van de 12-factor en mogen nooit worden gebruikt of op worden vertrouwd. Session state data is een goede kandidaat voor een datastore die time-expiration biedt, zoals [Memcached](http://memcached.org/) of [Redis](http://redis.io/).
diff --git a/content/nl/toc.md b/content/nl/toc.md
new file mode 100644
index 000000000..8ca46af7e
--- /dev/null
+++ b/content/nl/toc.md
@@ -0,0 +1,38 @@
+De Twaalf Factoren
+==================
+
+## [I. Codebase](./codebase)
+### Eén codebasis bijgehouden in versiebeheer, veel uitrollen
+
+## [II. Afhankelijkheden](./dependencies)
+### Expliciet afhankelijkheden declareren en isoleren
+
+## [III. Configuratie](./config)
+### Config opslaan in de omgeving
+
+## [IV. Backing-services](./backing-services)
+### Behandel backing services als bijgevoegde bronnen
+
+## [V. Build, release, run](./build-release-run)
+### Strikt gescheiden houden van build en run stadia
+
+## [VI. Processen](./processes)
+### De app als één of meer stateloze processen uitvoeren
+
+## [VII. Poort-binding](./port-binding)
+### Exporteer diensten via poort binding
+
+## [VIII. Concurrency](./concurrency)
+### Schaalvergroting via het procesmodel
+
+## [IX. Wegwerpbaarheid](./disposability)
+### Maximaliseer robuustheid met snel opstarten en elegant afsluiten
+
+## [X. Dev/prod-pariteit](./dev-prod-parity)
+### Hou ontwikkeling, staging, en productie zo gelijk mogelijk
+
+## [XI. Logs](./logs)
+### Behandel logs als event streams
+
+## [XII. Admin-processen](./admin-processes)
+### Voer admin/beheertaken uit als eenmalige processen
diff --git a/content/nl/who.md b/content/nl/who.md
new file mode 100644
index 000000000..248e62051
--- /dev/null
+++ b/content/nl/who.md
@@ -0,0 +1,4 @@
+Wie zou dit document moeten lezen?
+==============================
+
+Elke ontwikkelaar die applicaties bouwt die draaien als een service. Ops ingenieurs die dergelijke toepassingen uitrollen of beheren.
\ No newline at end of file
diff --git a/locales/nl.yml b/locales/nl.yml
new file mode 100644
index 000000000..7ed2cb270
--- /dev/null
+++ b/locales/nl.yml
@@ -0,0 +1,7 @@
+en:
+ # Name of language listed in locales menu
+ language: Nederlands (nl)
+
+ # A text to make known that the article is a translation not an original.
+ # Empty for English, original.
+ translation: "Deze tekst is een vertaling"
+
+Resources kunnen naar believen aan deploys worden toegevoegd of ervan worden losgekoppeld. Bijvoorbeeld, als de database van de app zich niet goed werkt vanwege een hardwareprobleem, kan de app-beheerder een nieuwe databaseserver opstarten die is hersteld vanaf een recente back-up. De huidige productiedatabase kan worden losgekoppeld en de nieuwe database aangekoppeld -- allemaal zonder enige codewijziging.
\ No newline at end of file
diff --git a/content/nl/build-release-run.md b/content/nl/build-release-run.md
new file mode 100644
index 000000000..e7d7dd1a4
--- /dev/null
+++ b/content/nl/build-release-run.md
@@ -0,0 +1,18 @@
+## V. Build, release, run
+### Strikt gescheiden houden van build en run stadia
+
+Een [codebase](./codebase) wordt getransformeerd in een (niet-ontwikkel) deploy door drie stadia:
+
+* De *build stage* is een transformatie die een code repo omzet in een uitvoerbare bundel, bekend als een *build*. Met behulp van een versie van de code op een commit gespecificeerd door het deployment proces, haalt de build fase vendors [dependencies](./dependencies) op en compileert binaries en assets.
+* De *release stage* neemt de geproduceerde build van de build stage en combineert het met de huidige [config](./config) van de deploy. De resulterende *release* bevat zowel de build als de config en is klaar voor onmiddellijke uitvoering in de uitvoeringsomgeving.
+* De *run fase* (ook bekend als "runtime") draait de app in de executie omgeving, door het starten van een set van de app's [processen](./processes) tegen een geselecteerde release.
+
+
+
+**De 12-factor app maakt gebruik van een strikte scheiding tussen de build, release en run stadia.** Het is bijvoorbeeld onmogelijk om wijzigingen aan te brengen in de code tijdens runtime, aangezien er geen manier is om die wijzigingen terug te propageren naar het build stadium.
+
+Deployment tools bieden meestal release management tools, met name de mogelijkheid om terug te gaan naar een vorige release. Bijvoorbeeld, de [Capistrano](https://github.com/capistrano/capistrano/wiki) deployment tool slaat releases op in een subdirectory genaamd `releases`, waar de huidige release een symlink is naar de huidige release directory. Het `rollback` commando maakt het makkelijk om snel terug te gaan naar een vorige release.
+
+Elke release moet altijd een unieke release ID hebben, zoals een tijdstempel van de release (zoals `2011-04-06-20:32:17`) of een oplopend nummer (zoals `v100`). Releases zijn een append-only grootboek en een release kan niet worden gemuteerd als deze eenmaal is aangemaakt. Elke verandering moet een nieuwe release aanmaken.
+
+Builds worden geïnitieerd door de ontwikkelaars van de app wanneer nieuwe code wordt uitgerold. Runtime uitvoering, daarentegen, kan automatisch gebeuren in gevallen zoals een server reboot, of een gecrasht proces dat opnieuw wordt gestart door de procesmanager. Daarom moet de run-fase beperkt worden tot zo weinig mogelijk bewegende delen, omdat problemen die een app verhinderen te draaien midden in de nacht kunnen gebeuren als er geen ontwikkelaars bij de hand zijn. De build fase kan complexer zijn, omdat fouten altijd op de voorgrond staan voor een ontwikkelaar die de deploy aanstuurt.
\ No newline at end of file
diff --git a/content/nl/codebase.md b/content/nl/codebase.md
new file mode 100644
index 000000000..c7feb98f6
--- /dev/null
+++ b/content/nl/codebase.md
@@ -0,0 +1,17 @@
+## I. Codebase
+### Eén codebasis bijgehouden in versiebeheer, veel uitrollen
+
+Een twelve-factor app wordt altijd bijgehouden in een versiebeheersysteem, zoals [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), of [Subversion](http://subversion.apache.org/). Een database voor het bijhouden van revisies staat bekend als een *code repository*, vaak afgekort tot *code repo* of gewoon *repo*
+
+Een *codebasis* is een enkele repo (in een gecentraliseerd revisiebeheersysteem zoals Subversion), of een set van repo's die een root commit delen (in een gedecentraliseerd revisiebeheersysteem zoals Git)
+
+
+
+Er is altijd een één-op-één correlatie tussen de codebase en de app:
+
+* Als er meerdere codebasissen zijn, is het geen app -- het is een gedistribueerd systeem. Elk onderdeel in een gedistribueerd systeem is een app, en elk kan individueel conform zijn met twelve-factor principes.
+* Meerdere apps die dezelfde code delen is een overtreding van de twelve-factor principes. De oplossing hier is om gedeelde code te herwerken in software-libraries die kunnen worden opgenomen in de [dependency manager](./dependencies).
+
+Er is slecht één codebase per app, maar er zullen veel uitrollen van de app zijn. Een *uitrol* is een draaiende instantie van de app. Dit is typisch voor een productie omgeving, en een of meer staging omgevingen. Daarnaast heeft elke ontwikkelaar een kopie van de app draaien in hun lokale ontwikkelomgeving, die ook gekwalificeert zijn als een uitrol.
+
+De codebasis is dezelfde over alle uitrollen, hoewel verschillende versies actief kunnen zijn in elke uitrol. Bijvoorbeeld, een ontwikkelaar heeft een aantal commits die nog niet zijn uitgerold naar staging; staging heeft een aantal commits die nog niet zijn uitgerold naar productie. Maar ze delen allemaal dezelfde codebasis, waardoor ze identificeerbaar zijn als verschillende uitrollen van dezelfde app.
\ No newline at end of file
diff --git a/content/nl/concurrency.md b/content/nl/concurrency.md
new file mode 100644
index 000000000..a6c72698a
--- /dev/null
+++ b/content/nl/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. Concurrentie
+### Schaalvergroting via het procesmodel
+
+Elk computerprogramma, eenmaal uitgevoerd, wordt vertegenwoordigd door een of meer processen. Web apps hebben een verscheidenheid aan procesuitvoeringsvormen aangenomen. PHP-processen bijvoorbeeld draaien als kindprocessen van Apache, die op verzoek worden opgestart naar gelang de hoeveelheid verzoeken. Java processen hebben de tegenovergestelde aanpak, waarbij de JVM één groot uberproces levert dat een groot blok systeembronnen (CPU en geheugen) reserveert bij het opstarten, met concurrency die intern beheerd wordt via threads. In beide gevallen is (zijn) het (de) lopende proces(sen) slechts minimaal zichtbaar voor de ontwikkelaars van de app.
+
+
+
+**In de 12-factor app zijn processen een eerste klas burger.** Processen in de 12-factor app zijn sterk afgeleid van [het unix procesmodel voor het draaien van service daemons](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Met behulp van dit model kan de ontwikkelaar zijn app ontwerpen om verschillende werkbelastingen aan te kunnen door elk type werk toe te wijzen aan een *procestype*. HTTP-verzoeken kunnen bijvoorbeeld worden afgehandeld door een webproces, en langlopende achtergrondtaken door een werkproces.
+
+Dit sluit niet uit dat individuele processen hun eigen interne multiplexing afhandelen, via threads in de runtime VM, of het async/evented model dat te vinden is in tools als [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), of [Node.js](http://nodejs.org/). Maar een individuele VM kan maar zo groot worden (verticale schaal), dus de applicatie moet ook in staat zijn om meerdere processen te overspannen die draaien op meerdere fysieke machines.
+
+Het procesmodel blinkt pas echt uit wanneer het tijd is om uit te schalen. De [niets delende, horizontaal partitioneerbare aard van 12-factor app processen] (./processes) betekent dat het toevoegen van meer concurrency een eenvoudige en betrouwbare operatie is. De reeks van procestypes en het aantal processen van elk type staat bekend als de *procesformatie*.
+
+12-factor app processen [moeten nooit daemoniseren](http://dustin.github.com/2010/02/28/running-processes.html) of PID-bestanden schrijven. Vertrouw in plaats daarvan op de procesmanager van het besturingssysteem (zoals [systemd](https://www.freedesktop.org/wiki/Software/systemd/), een gedistribueerde procesmanager op een cloud-platform, of een tool zoals [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) in ontwikkeling) om [uitvoerstromen](./logs) te beheren, te reageren op gecrashte processen, en door de gebruiker geïnitieerde herstarts en shutdowns af te handelen.
\ No newline at end of file
diff --git a/content/nl/config.md b/content/nl/config.md
new file mode 100644
index 000000000..7488f0603
--- /dev/null
+++ b/content/nl/config.md
@@ -0,0 +1,22 @@
+## III. Configuratie
+### Config opslaan in de omgeving
+
+De *config* van een app is alles wat waarschijnlijk varieert tussen [deploys](./codebase) (staging, productie, ontwikkelomgevingen, etc). Dit omvat:
+
+* Resource handles naar de database, Memcached, en andere [backing-services](./backing-services)
+* Credentials naar externe diensten zoals Amazon S3 of Twitter
+* Per-deploy waarden zoals de canonieke hostnaam voor de deploy
+
+Apps slaan soms config op als constanten in de code. Dit is een schending van de 12-factors, die **strikte scheiding van config en code** vereist. Config varieert aanzienlijk tussen deploys, code niet.
+
+Een lakmoesproef voor het feit of een app alle configuratie correct uit de code heeft gehaald, is of de codebase op elk moment open source kan worden gemaakt, zonder de credentials te compromitteren.
+
+Merk op dat deze definitie van "config" **niet** interne applicatie config omvat, zoals `config/routes.rb` in Rails, of hoe [code modules zijn verbonden](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) in [Spring](http://spring.io/). Dit type van configuratie varieert niet tussen deploys, en wordt dus best in de code gedaan.
+
+Een andere benadering van config is het gebruik van config bestanden die niet ingecheckt worden in revisie controle, zoals `config/database.yml` in Rails. Dit is een enorme verbetering ten opzichte van het gebruik van constanten die in de code repo worden ingecheckt, maar heeft nog steeds zwakke punten: het is gemakkelijk om per ongeluk een config bestand in de repo in te checken; er is een neiging voor config bestanden om verspreid te zijn over verschillende plaatsen en verschillende formaten, wat het moeilijk maakt om alle config op één plaats te zien en te beheren. Verder hebben deze formaten de neiging programmeertaal- of framework-specifiek te zijn.
+
+**De 12-factor app slaat de configuratie op in *environment variables*** (vaak afgekort tot *env vars* of *env*). Env vars zijn gemakkelijk te veranderen tussen deploys zonder code te veranderen; in tegenstelling tot config files, is er weinig kans dat ze per ongeluk in de code repo ingecheckt worden; en in tegenstelling tot custom config files, of andere config mechanismen zoals Java System Properties, zijn ze een programmeertaal- en OS-agnostische standaard.
+
+Een ander aspect van config management is groeperen. Soms groeperen apps hun config in benoemde groepen (vaak "omgevingen" genaamd), genoemd naar specifieke deploys, zoals de `development`, `test`, en `production` omgevingen in Rails. Deze methode schaalt niet netjes: als meer deploys van de app worden gemaakt, zijn nieuwe omgevingsnamen nodig, zoals `staging` of `qa`. Als het project verder groeit, kunnen ontwikkelaars hun eigen speciale omgevingen toevoegen, zoals `joes-staging`, wat resulteert in een combinatorische explosie van config die het beheren van deploys van de app erg broos maakt.
+
+In een 12-factor app, zijn env vars granulaire controls, elk volledig orthogonaal aan andere env vars. Ze worden nooit gegroepeerd als "omgevingen", maar worden in plaats daarvan onafhankelijk beheerd voor elke implementatie. Dit is een model dat soepel opschaalt naarmate de app zich op natuurlijke wijze uitbreidt naar meer implementaties gedurende zijn levensduur.
\ No newline at end of file
diff --git a/content/nl/dependencies.md b/content/nl/dependencies.md
new file mode 100644
index 000000000..57ae64551
--- /dev/null
+++ b/content/nl/dependencies.md
@@ -0,0 +1,12 @@
+## II. Afhankelijkheden
+### Expliciet afhankelijkheden declareren en isoleren
+
+De meeste programmeertalen bieden een packaging systeem voor het distribueren van ondersteunende bibliotheken aan, zoals [CPAN](http://www.cpan.org/) voor Perl of [Rubygems](http://rubygems.org/) voor Ruby. Libraries die via een packaging systeem worden geïnstalleerd, kunnen systeembreed worden geïnstalleerd (bekend als "site packages") of worden opgenomen in de map die de app bevat (bekend als "vendoring" of "bundling").
+
+**Een 12-factor app vertrouwt nooit op het impliciete bestaan van systeembrede libraries.** Het declareert alle afhankelijkheden, volledig en exact, via een *dependency declaration* manifest. Bovendien gebruikt het een *dependency isolation* tool tijdens de uitvoering om te verzekeren dat er geen impliciete afhankelijkheden naar binnen lekken vanuit het omringende systeem. De volledige en expliciete afhankelijkheidsspecificatie wordt uniform toegepast op zowel productie als ontwikkeling.
+
+Bijvoorbeeld, [Bundler](https://bundler.io/) voor Ruby biedt het `Gemfile` manifest formaat voor dependency declaratie aan en `bundle exec` voor dependency isolatie. In Python zijn er twee aparte gereedschappen voor deze stappen -- [Pip](http://www.pip-installer.org/en/latest/) wordt gebruikt voor declaratie en [Virtualenv](http://www.virtualenv.org/en/latest/) voor isolatie. Zelfs C heeft [Autoconf](http://www.gnu.org/s/autoconf/) voor dependency declaratie, en static linking kan voor dependency isolatie zorgen. Ongeacht de toolchain, dependency declaratie en isolatie moeten altijd samen gebruikt worden -- alleen het een of het ander is niet voldoende om aan de twaalf-factor te voldoen.
+
+Een voordeel van expliciete dependency declaratie is dat het de setup vereenvoudigt voor ontwikkelaars die nieuw zijn voor de app. De nieuwe ontwikkelaar kan de codebase van de app uitchecken op zijn ontwikkelmachine, waarbij hij alleen de runtime van de taal en de dependency manager als vereisten hoeft te installeren. Ze kunnen alles instellen wat nodig is om de code van de app te draaien met een deterministisch *build-commando*. Bijvoorbeeld, het build commando voor Ruby/Bundler is `bundle install`, terwijl het voor Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) `lein deps` is.
+
+12-factor apps vertrouwen ook niet op het impliciete bestaan van systeemtools. Voorbeelden hiervan zijn het uitzetten naar ImageMagick of `curl`. Hoewel deze hulpprogramma's op veel of zelfs de meeste systemen bestaan, is er geen garantie dat ze op alle systemen bestaan waarop de app in de toekomst kan draaien, of dat de versie die op een toekomstig systeem wordt gevonden compatibel zal zijn met de app. Als de app moet uitwijken naar een systeemhulpprogramma, moet dat programma in de app worden opgenomen.
\ No newline at end of file
diff --git a/content/nl/dev-prod-parity.md b/content/nl/dev-prod-parity.md
new file mode 100644
index 000000000..b8c4d5633
--- /dev/null
+++ b/content/nl/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. Dev/prod pariteit
+### Hou ontwikkeling, staging, en productie zo gelijk mogelijk
+
+Historisch gezien zijn er aanzienlijke verschillen geweest tussen ontwikkeling (een ontwikkelaar die live bewerkingen uitvoert op een lokale [deploy](./codebase) van de app) en productie (een draaiende deploy van de app die toegankelijk is voor eindgebruikers). Deze verschillen manifesteren zich op drie gebieden:
+
+* **De tijdskloof**: Een ontwikkelaar kan werken aan code die er dagen, weken of zelfs maanden over doet om in productie te gaan.
+* **De personeelskloof**: Ontwikkelaars schrijven code, ops ingenieurs implementeren het.
+* **De tools gap**: Ontwikkelaars gebruiken misschien een stack als Nginx, SQLite en OS X, terwijl de productie Apache, MySQL en Linux gebruikt.
+
+**De 12-factor app is ontworpen voor [continue implementatie](http://avc.com/2011/02/continuous-deployment/) door de kloof tussen ontwikkeling en productie klein te houden.** Kijkend naar de drie hierboven beschreven kloven:
+
+* Maak de tijdskloof klein: een ontwikkelaar kan code schrijven en deze uren of zelfs slechts minuten later laten implementeren.
+* Maak de kloof tussen personeel klein: ontwikkelaars die code hebben geschreven zijn nauw betrokken bij het implementeren van de code en kijken naar het gedrag ervan in productie.
+* Maak de tools gap klein: zorg dat ontwikkeling en productie zo veel mogelijk op elkaar lijken.
+
+Vat het bovenstaande samen in een tabel:
+
+