diff --git a/README.rst b/README.rst
index d788105..1ef57f5 100644
--- a/README.rst
+++ b/README.rst
@@ -34,52 +34,41 @@ The resulting wheels are therefore self-contained and do not need any external
 dynamic libraries apart from those provided as standard by OSX / Linux as
 defined by the manylinux standard.
 
-The ``.travis.yml`` file in this repository has a line containing the API key
-for the Rackspace container encrypted with an RSA key that is unique to the
-repository - see http://docs.travis-ci.com/user/encryption-keys.  This
-encrypted key gives the travis build permission to upload to the Rackspace
-directory pointed to by http://wheels.scipy.org.
+The ``azure/*`` files in this repository read a token stored in the Azure
+Pipeline used to run the CI.  This encrypted key gives Azure permission to
+upload to the ananconda.org directories ``https://anaconda.org/<user>/numpy/``
+where user is the ``ANACONDA_ORG`` value in the ``yml`` files.
 
 Triggering a build
 ==================
 
-You will likely want to edit the ``.travis.yml`` and ``appveyor.yml`` files to
+You will likely want to edit the ``azure/*`` files to
 specify the ``BUILD_COMMIT`` before triggering a build - see below.
 
-You will need write permission to the github repository to trigger new builds
-on the travis-ci interface.  Contact us on the mailing list if you need this.
+You will need write permission to the github repository to trigger new builds.
+Contact us on the mailing list if you need this.
 
 You can trigger a build by:
 
 * making a commit to the `numpy-wheels` repository (e.g. with `git
   commit --allow-empty`); or
-* clicking on the circular arrow icon towards the top right of the travis-ci
-  page, to rerun the previous build.
-
-In general, it is better to trigger a build with a commit, because this makes
-a new set of build products and logs, keeping the old ones for reference.
-Keeping the old build logs helps us keep track of previous problems and
-successful builds.
+* merging a pull request to the repo
 
 Which numpy commit does the repository build?
 ===============================================
 
-The `numpy-wheels` repository will build the commit specified in the
-``BUILD_COMMIT`` at the top of the ``.travis.yml`` and ``appveyor.yml`` files.
-This can be any naming of a commit, including branch name, tag name or commit
-hash.
+PRs merged to this repo from a fork, and commits directly pushed to this repo
+will build the commit specified in the ``BUILD_COMMIT`` at the top of the
+``azure/windows.yml`` and ``azure/posix.yml`` files, the wheels will be
+uploaded to https://anaconda.org/multibuild-wheels-staging/numpy. The
+``NIGHTLY_BUILD_COMMIT`` is built once a week (sorry for the misnomer),
+and uploaded to https://anaconda.org/scipy-wheels-nightly/.
+The value of ``BUILD_COMMIT`` can be any naming of a commit, including branch
+name, tag name or commit hash.
 
 Uploading the built wheels to pypi
 ==================================
 
-Be careful, http://wheels.scipy.org points to a container on a distributed
-content delivery network.  It can take up to 15 minutes for the new wheel file
-to get updated into the container at http://wheels.scipy.org.
-
-The same contents appear at
-https://3f23b170c54c2533c070-1c8a9b3114517dc5fe17b7c3f8c63a43.ssl.cf2.rackcdn.com;
-you might prefer this address because it is https.
-
 When the wheels are updated, you can download them to your machine manually,
 and then upload them manually to pypi, or by using twine_.  You can also use a
 script for doing this, housed at :
@@ -92,7 +81,7 @@ You will typically have a directory on your machine where you store wheels,
 called a `wheelhouse`.   The typical call for `wheel-uploader` would then
 be something like::
 
-    CDN_URL=https://3f23b170c54c2533c070-1c8a9b3114517dc5fe17b7c3f8c63a43.ssl.cf2.rackcdn.com
+    CDN_URL=https://anaconda.org/multibuild-wheels/staging/numpy/files
     wheel-uploader -r warehouse -u $CDN_URL -s -v -w ~/wheelhouse -t macosx numpy 1.11.1
     wheel-uploader -r warehouse -u $CDN_URL -s -v -w ~/wheelhouse -t manylinux1 numpy 1.11.1
     wheel-uploader -r warehouse -u $CDN_URL -s -v -w ~/wheelhouse -t win numpy 1.11.1
diff --git a/azure-pipelines.yml b/azure-pipelines.yml
index be7193c..e78f9cb 100644
--- a/azure-pipelines.yml
+++ b/azure-pipelines.yml
@@ -76,6 +76,31 @@ jobs:
         py_3.8_64:
           MB_PYTHON_VERSION: "3.8"
           MB_ML_VER: "2010"
+        # manylinux1 wheels
+        py_3.6_32manylinux1:
+          MB_PYTHON_VERSION: "3.6"
+          PLAT: "i686"
+          MB_ML_VER: "1"
+          ENV_VARS_PATH: "env_vars_32.sh"
+        py_3.6_64manylinux1:
+          MB_PYTHON_VERSION: "3.6"
+          MB_ML_VER: "1"
+        py_3.7_32manylinux1:
+          MB_PYTHON_VERSION: "3.7"
+          PLAT: "i686"
+          MB_ML_VER: "1"
+          ENV_VARS_PATH: "env_vars_32.sh"
+        py_3.7_64manylinux1:
+          MB_PYTHON_VERSION: "3.7"
+          MB_ML_VER: "1"
+        py_3.8_32manylinux1:
+          MB_PYTHON_VERSION: "3.8"
+          PLAT: "i686"
+          MB_ML_VER: "1"
+          ENV_VARS_PATH: "env_vars_32.sh"
+        py_3.8_64manylinux1:
+          MB_PYTHON_VERSION: "3.8"
+          MB_ML_VER: "1"
 
   - template: azure/posix.yml
     parameters:
diff --git a/azure/posix.yml b/azure/posix.yml
index 01d8253..c4f8d20 100644
--- a/azure/posix.yml
+++ b/azure/posix.yml
@@ -9,7 +9,7 @@ jobs:
       vmImage: ${{ parameters.vmImage }}
     variables:
       REPO_DIR: "numpy"
-      BUILD_COMMIT: 'v1.18.3'
+      BUILD_COMMIT: 'f1be9e50ff'  # needed for 32 bit builds, should become 1.18.4
       PLAT: "x86_64"
       CYTHON_BUILD_DEP: "cython==0.29.16"
       NIGHTLY_BUILD_COMMIT: "master"