I'm about to rename my Heroku app from the default one that it started with - just some jibberish, really - to something that's a little more sensical. I'm also about to wire it up with a custom domain. Is changing the app name going to cause any problems? I've read the docs and it seems like it'll be okay but wanted to ask to be sure that there weren't any namespace issues, etc. Thanks!
If you have already configured custom domain on Heroku app. And then changed the name of the application on heroku, then you will need to update the required CNAME and A record which are pointing to earlier.herokuapp.com
If you haven't added the custom domain yet, rename the app first, then add the domain.
Good luck
You can use command line also just use below command from your project folder, by below command you no need to point to new from your git. It will automatically update your git too.
heroku apps:rename NEWNAME --app APP
NEWNAME is your new name for your heroku app
APP is old name already existing one.
If you don't know exatly the old name then you can able to view list of names and their addresses by below command
git remote -v
Related
I have a Heroku app that is running on the Cedar-10 stack which will soon be deprecated. I am following the Migrating to the Celadon Cedar-14 Stack guide and have created an instance of my app on the new stack. However, this has also created another (empty) PostgreSQL database automatically.
Can I upgrade to the new stack but continue to use the existing database?
When I delete app on the old stack, will it delete the database that is associated with it automatically?
I see that the database URL is set in the environment variable $DATABASE_URL - does that mean I can somehow update that and "link" the old database to the new app?
When searching for information on this I've come across heroku's pg:copy and pg:transfer directives, but it seems strange to duplicate the database when it is working fine, and has a paid "upgrade" and backups already associated with it.
The problem with the configuration variable approach
While it is possible to share a database between two applications in Heroku by copying the DATABASE_URL configuration variable of the first application to the second, only the first application will have a primary connection (add-on) to the database.
If you remove the first application, your database will disappear from the postgres dashboard in Heroku. Although it seems the second application will still be able to use the database. (Tested on 2015-10-25.)
It is also worth noting that:
Heroku do reserve the right to change database URLs as required. If this occurs, it will cause your secondary connections to fail, and you'll need to update the URLs accordingly.
What this means is that if Heroku decide to change the URL for your database, your new application will fail, and since the database is now gone from your dashboard, you will not be able to retrieve the new URL without approaching Heroku. (If at all.)
This implies that there is a more intrinsic connection between an application and its database than merely the DATABASE_URL, and it might not be the best idea to use this as a mechanism for transfer.
An alternative approach using PGBackups
Heroku official documentation recommends using the free PGBackups add-on (which, honestly, you should always be running anyway) to transfer data between Postgres instances. The tool uses the native pg_dump and pg_restore tools.
Particularly, you can use the PG copy feature, described below:
PG copy uses the native PostgreSQL backup and restore utilities. Instead of writing the backup to a disk however, it streams it over the wire directly to the restore process on the new database.
They conveniently provide a means for you to copy a database between applications with a single command, and without any intermediate storage required:
As an alternative, you can migrate data between databases that are attached to different applications.
To copy the source database to the target database you will need to invoke pg:copy from the target application, referencing a source database.
Example:
heroku pg:copy source-application::OLIVE HEROKU_POSTGRESQL_PINK -a target-application
Where source-application is your existing stack, and target-application your newly created one. Not relevant to you, but still worth mentioning, is that any existing data in target-applications database will be destroyed.
After this, you might need to promote the database in the new application like so:
heroku pg:promote HEROKU_POSTGRESQL_PINK
You certainly can change your configuration variables to point from the new app's database to the existing database. I've done this before without issue (just make sure you have a fresh backup).
So within your new app run heroku config. You'll see a reference to your database in DATABASE_URL. You can then change the value with:
heroku config:set DATABASE_URL=<existing-database-url>
At that point you'd have your old app and new app pointing at the same database without issue. As you said, you're paying for the database upgrade on your existing database so deleting your old app shouldn't delete the database; if it does (again you have backups right?) that would be the time to contact Heroku!
If you're not comfortable working with the command line, you can also change the values in your app's Settings tab on the Heroku app dashboard.
With all of that said, you shouldn't actually need to create a new app in order to upgrade your stack. Again, I've done a stack upgrade before and you ought to be able to do it in place; which the Heroku docs confirm.
Although #Drenmi's approach is probably the safest option it is possible to transfer database "ownership" between apps.
Make sure you make a backup first.
In Heroku databases are treated as Add-Ons. So when you for example push a rails app heroku will add a postgres db addon to the app.
First use heroku addons to get a list of the addons attached:
$ heroku addons --app old_app
Add-on Plan Price
─────────────────────────────────────── ──── ─────
heroku-postgresql (resting-fairly-4672) dev free
└─ as HEROKU_POSTGRESQL_CYAN
We can then attach the database to the new app.
heroku addons:attach resting-fairly-4672 --app new_app
And detach it from the old app.
heroku addons:detach resting-fairly-4672 -app old_app
See https://devcenter.heroku.com/articles/managing-add-ons
I'm trying to upload my db dump file to Heroku to manage the website. It's a static file. When I follow the instruction given in Heroku site, I got errors. I might get it wrong so want to be clarified by many experts. Please help me!
What is the app sushi? I kept trying to push my db dump file to Heroku server. All configuration is set.
This is a command I put.
$heroku pg:push outfile HEROKU_POSTGRESQL_MAUVE --app sushi
This is a result I got.
You do not have permission to view resources for sushi.
You need to have the deploy privilege on this app.
When I command
$heroku config
AWS, DATAbase URL, Bucket name etc are well set. Many commands I see from this link https://devcenter.heroku.com/articles/heroku-postgresql and none of them worked to me because I don't have a permission to app sushi. How can I get the permission?
sushi is just the example app name given for reference , please replace sushi with the actual name of your application.
Yes, it is confusing. Like "infused" commented, "sushi" is an example app name, you should replace that with the app name you have.
If your app name is "apidata", then you should write:
$heroku pg:push outfile HEROKU_POSTGRESQL_MAUVE --app apidata
You can find your app name in the app menu and in the url like this:
https://dashboard.heroku.com/apps/apidata
being "apidata" your app name.
Kind of late, but might help future doubts since this tutorial is still this confusing.
I have developed a RoR app. I would like to update it to handle more than one customer. For instance, one customer might use ame.requestsys.com and another would be slc.requestsys.com.
Currently on Heroku, I have requestsys.com and www.requestsys.com
I was told that I need to have *.requestsys.com --> is that correct?
If yes, why won't Heroku let me add it?
Thanks
From the command line in the directory of your app do:
$ heroku domains:add *.requestsys.com
You can also do it from the heroku dashboard.
Then setup a CNAME in your DNS accordingly to point to yourapp.herokuapp.com
Try this guide for more info: https://devcenter.heroku.com/articles/custom-domains#wildcard-domains.
Basically what you wanna do is a multitenant app, there are a couple railscasts on the subject:
http://railscasts.com/episodes?search=multitenancy
But thats beyond the scope of the question.
I'm new to rails and heroku, and this may very well seem like a daft question, if so I appologise, but would appreciate someone at least telling me so.
I've followed the heroku "getting started" guide, and managed to deploy a copy of the rails default project. But the url preovided by heroku was http://radiant-ice-84.heroku.com, my question is this:
Does heroku assign a randomly generated url, or have I done something wrong because I don't recognise radiant-ice-84?
Before you closing this question, I would like to say that you in fact could specify the first when you create the app (no need to change again in the setting page) by using:
heroku create your-app-name
If you don't specify a name, Heroku generates one for you. You can change it in your app settings (as you noticed), although a lot of people just buy a domain name and map it to the Heroku-generated name.
Firstly, Happy New Year everyone.
I'm new to Rails, so please tolerate any incorrect use of terminology...
I have developed a simple Rails application, backed by a MySQL database.
I would now like to deploy this application to multiple, independent groups of users (i.e. it is a club application, and I would like to deploy it to a number of completely independent clubs).
I would like to use the same Rails Application code as much as possible, and just have a separate instance of the database for each club.
As each instance will be running on the same server (until server load proves to be an issue) I assume I can use a different port for each Rails server to steer users to the correct group?
I'd read that there are test and production modes, is it possible to have multiple [additional] instances of production modes, e.g. club1, club2, all sharing the same code, with unique databases?
My questions are how to support multiple separate database instances, and also how best to route to these?
Any advice on how to go about this much appreciated.
If you are using Git (I suggest you should be!) then you can keep a central version of your code in one place and then deploy it multiple times, changing only the database.yml file (it should not be checked in to your git repository in that case). http://git-scm.com/
Let's say you put all of your code up on github.com with username 'snips' and the project is called 'clubster'. Using something like Heroku you would then do:
git clone https://github.com/snips/clubster.git
cd clubster
heroku create boxingclub
Because Heroku auto-configures your database there is no need for a database.yml file
git push heroku master
And you'd have a version of your code deployed at boxingclub.heroku.com
When you make changes to your code you just go to each of your installations and do:
git pull origin master
git push heroku master
Which updates your code on that particular instance of your application.
And if you're getting a little more advanced you'd be looking at Chef to manage the whole setup for you. http://www.rubyinside.com/chef-tasty-server-configuraiton-2162.html
The other approach would be to have some kind of subdomain system, but I'll leave that to others to cover.