This page has my Tips and Tricks for deploying a web2py app onto the GAE Last Updated: 2010-11-13
The quickest way to see something happen on GAE with web2py is to deploy the T3 'Appliance'.
The T3 download is here http://mdp.cti.depaul.edu/examples/static/web2py.app.t3.tar
The T2, T3 posting is here http://groups.google.com/group/web2py/browse_thread/thread/4f2a57560f556d8d
Appliances are free ready-to-deploy apps that come with web2py, but there is a 'gotcha' that not all of the Appliances are ready to run on GAE. For example, the 'TonyBlog' Appliance only runs on a SQL engine. It will not work on GAE unless a few lines of code are changed to make it store the photo images in the datastore rather than in files. Also, a lot of the Appliances have an Administration Menu and built-in security checks which cause the app to hang on GAE. TonyBlog is a particularly nasty Appliance to port to GAE. However, if you know where to look, it is just a few lines to change.
T3 however, is a GAE 'darling'. Just deploy it to GAE and voila, it runs!
In the web2py development environment, after you log into the Administration page which is typically at
there is an area at the bottom to 'upload application:' There you would Browse to select web2py.app.t3.tar and then fill in a name of your choice in the edit field labelled 'and rename it:'. For this article, assume the name is 'T3'. That will cause web2py to create a T3 folder under the 'applications' folder. The .tar will be unpacked into the T3 folder.
Assuming you just know ASP.NET, C# and IIS, you are going to want a step by step process for getting your own copy of T3 to run on your own subdomain of appspot.com.
This article will give the detailed steps.
Finally, I will detail the additional steps to point a domain which you own to your appspot app.
Basically, you just deal with a whole bunch of .py source files, and never do any Python compiling. No .EXEs or dlls are deployed to GAE. However there is a catch related to getting visual debugging working. Because of the architecture of the Google App Engine web server and the way web2py interacts with it, all of the code which is intended to be visually debugged with breakpoints and step thru, must be in python 'modules'. If you write a normal web2py application NOT intended for GAE, then visual debugging will work on all the python code without needing to package it into modules. But on the App Engine framework, python modules are the only code units which will allow setting visual debugger breakpoints.
And even though you execute web2py.exe (the compiled .py engine) to develop on your local machine, when it comes time to deploy to the local GAE SDK, or onto the real GAE, you must deploy the SOURCE CODE for web2py and then inside the web2py source folder there is folder 'applications' and insdie that you put the source for T3. Typically you would create a directory structure C:\Google\AppEngine\web2py for your locally deployed web2py code.
Fortunately the web2py source code is very easy to download. No need to use SVN client.
Just go to this page http://www.web2py.com/examples/default/download and click on the orange 'source code' link:
source code for all platforms (requires Python 2.5, runs on Windows and most Unix systems,
You would copy T3 into C:\Google\AppEngine\web2py\applications
so you would then have the folder C:\Google\AppEngine\web2py\applications\T3
Then you should rename T3 to be init. Do that so that when you deploy to the read GAE you will be able to run it just by typing your domain without needing to specify any subfolder. web2py automatically searches for and runs whatever is in init.
Then you must edit C:\Google\AppEngine\web2py\app.yaml and set application: to be your registered application id which must be one of the limit of 10 registered App Engine application ids which Google allows you to register. For this example we will assume it is 'myappid'.
The GAE SDK installs itself into C:\Program Files\Google\google_appengine
and it adds that folder to the PATH.
Then a typical script to test your web2py app locally on the GAE SDK engine would be
That will run your web2py app on the locally simulated GAE (using the GAE SDK).
Once you are happy, you can deploy it by running
appcfg.py -v update web2py/
appcfg will look at web2py/app.yaml for the application: name and that will be the target registered application for the upload.
Once upload is complete, you can test it on the real GAE at http://my appid .appspot.com
If you remove the file from your local development directory then upload the app using the same "version" parameter in the app.yaml file, the file will be deleted from App Engine. If the file is in a different "version" of the app and the version is no longer the default version, you can delete the entire version from the Admin Console.
In the Admin console , you wouldn't delete a file, you'd delete a version of the application. See the Versions section of the Admin Console.
If you want to delete a file from the current version, simply delete it locally, then re-upload the app. You don't need the Admin Console for that.
When you log into the Administrator panel for a particular one of your registered GAE Application Ids (the URL of the Administration panel is typically http://appengine.google.com/dashboard/nonedeployed?appid=myappid ), there is a menu link on the left side named ' Versions '. When you click on 'Versions' it takes you to a page which has an edit box labelled 'Domain Name' and a button to 'Add Domain'. Enter the name of the domain which you own that you want to be used for accessing this particular GAE application (which is already accessible as http://myappid.appspot.com ). Click the 'Add Domain... ' button to access a page which then has an Agreement checkbox and an 'Activate this Service' button . Click the 'Activate this Service' button and you will be taken to a page titled ' myappid Settings' which has the textbox where you must enter the subdomain name that you wish to map to. Typcially you would enter 'www'. Then click the 'Add' button. Now you will be redirected to the final page of the domain mapping process, which is titled 'Changing CNAME record'. This has instructions for changing the CNAME record and then a button labelled 'I've completed these steps'.
Typically you would contact your DNS hosting service or sign on to the control panel of your DNS hosting service and do 2 things:
first, delete all 'A' records for the domain
second: Create a CNAME record following the guidelines given on the 'Changing CNAME record' page to map 'www' subdomain of 'mydomain.com' to a special google url which is ghs.google.com. Also there may be a step to add a second CNAME record containing a guid (very long number of digits) to prove that you are the owner of the domain.
Once that is done and you click the 'I've completed these steps' button, then you must wait a few hours before finally you can access your GAE application as http://www.mydomain.com .
An easy and low cost way to buy a domain for your GAE appspot site is to buy it for $10 through Google at https://www.google.com/a/cpanel/domain/new which then forwards your purchase to the GoDaddy.com registrar. This process will automatically configure your new domain as a Google Apps app, which is not the same thing as setting it up for use in a Google App Engine site. But there is a way to 'back out' the Google Apps service relationship from your new domain, leaving it then available for use by your App Engine application. Simply log into your Google Apps account for the newly purchased domain and click the Services tab. There you will find an option to remove the Google Apps service. Follow that procedure. Next you must sign on to the Godaddy Registrar admin site for your new domain and DELETE ALL 'A' RECORDS (to eliminate the designation that your web pages are hosted by Godaddy). To delete an 'A" record on the GoDaddy DNS manager web page, click the small circled 'x' on the right size of the page for each 'A' record. Now you will be able to add your domain into App Engine.
- The maximum size for a given request is 10 megabytes, as documented
in http://code.google.com/appengine/docs/java/runtime.html#Quotas_and_Li... .
This means that you can post up to 10 megabytes of file and/or other
request data without error, but keep in mind that a datastore entity
can contain at most 1 megabyte, which is also the cap for data input
to image service functions