I have two approaches to this, both of which have served well. I'll start with the easiest approach first, which is what I'd call a "static". I use this when I don't have many environment-specific settings... maybe a small handful.
I'm assuming you have an Application.cfc or .cfm file for your app. In there, you could set a variable, something like "application.environment", and by default it'd be set to "dev". Throughout your app you could inspect that variable to determine where you are.
When you package your application for deployment, you could then change that Application.cfc file to read "" instead.
Now, that's going to get annoying, so I just use ant for this. I just use something like this in my build.xml, which lives in the same directory as Application.cfc:
<replace file="Application.cfc" token="DEV" value="PROD" casesensitive="true" />
And then zip the app for deployment:
<zip destfile="${zipdir}/MyApp-Production.zip">
<zipfileset dir="." prefix="MyApp" />
</zip>
Then I deploy the zip. If I'm working on a small project that uses FTP instead of some corporate enterprisey deployment hooey, then I'll just have an ANT task that FTPs files to my production server and it'll also perform that replace on Application.cfc and push that file, too.
For most of the apps I work on where I work, we use two database tables to manage environments. We do this because we have a lot of different environments, and each one has different settings, usually centered around filesystem and network paths that differ per environment (let's not talk about why they're different... totally separate discussion). So We have a table we call "AppLocations":
LocationID | LocName | LocDesc | Setting1 | Setting2 | Setting 3| ......
1 | Local | 'Localhost Environment' | whatever.....
2 | Dev | 'Development Environment' | whatever....
3 | Test | 'Test Environment' | whatever.....
and so on.
Then, we have another table named "AppLocationHosts"
LocationID | LocHostName
1 | 'localhost'
2 | 'devservername'
2 | 'otherdevservername'
3 | 'testservername'
3 | 'othertestserver'
and so on.
then, in Application.cfc, in onApplicationStart, we do this query
SELECT TOP 1 *
FROM AppLocations
WHERE LocationID IN (SELECT LocationID FROM AppLocationHosts WHERE LocHostName = <cfqueryparam value="#CGI.HTTP_HOST#" cfsqltype="cf_sql_varchar"/>)
And from there, once we know what location we're in based on the http_host match, we set those "Setting" columns into the application scope:
<cfloop list="#qryAppPathLocations.ColumnList#" index="ColName">
<cfset application[ColName] = qryAppPathLocations[ColName]>
</cfloop>
This approach isn't for everyone, but in our weird environment where consistency is unusual, it's been a very flexible approach.
Now, if you literally only have two environments, and one of them is "localhost" and the other is "www.myapp.com", then by far the easiest would be to just do a check on http_host in onApplicationStart and if you're in "www.myapp.com", then you do your production-specific setup. Perhaps here you set stuff like "request.querydebug = true" and then when you're in production, you turn that off. Then your queries could use that flag to determine whether to turn debug on or off for the cfstoredproc and query. Though I must say, I strongly recommend against that.